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ABSTRACT 


This  report  describes  an  initial  study  concerning  the  feasibility 
of  proving  the  correctness  (i.e.,  verification)  of  COBOL  programs.  The 
report  contains: 

(1)  A  study  of  the  COBOL  language  as  related  to  verification. 

(2)  The  syntax  and  semantics  of  a  subset  of  COBOL  74  in  which 
to  perform  experimental  verification. 

(3)  Design  of  a  system  to  accomplish  COBOL  verification  in  the 
desired  subset. 

(4)  Proof  of  a  sample  COBOL  program. 

The  conclusion  of  the  report  is  that  COBOL  verification  is  Indeed  feasible, 
but  must  be  further  engineered  if  it  is  to  be  cost-effective. 


PREFACE 


For  readers  who  want  only  a  summary  of  COBOL  verification  work, 
we  suggest  reading  Sections  I,  II,  III,  and  VII.  The  introductions 
and  conclusions  to  the  remaining  sections  may  also  be  helpful.  A 
glossary  is  provided  that  defines  terms  pertinent  to  program  verifi¬ 
cation.  We  do  not  suggest  reading  the  Appendix  unless  the  reader  is 
interested  in  the  inner  workings  of  the  COBOL  verification  system 
and  has  some  background  in  LISP. 

The  authors  acknowledge  the  assistance  of  Jack  Goldberg  and 
Karl  N.  Levitt  in  the  management  of  this  project,  and  the  technical 
assistance  provided  by  Robert  S.  Boyer  and  Bernard  Elspas. 
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I  INTRODUCTION 


A.  Introduction 

The  goal  of  this  project  has  been  to  study  the  feasibility  of  formal 
verification  of  COBOL  programs.  To  do  that,  we  have  chosen  a  subset  of 
the  COBOL  and  built  part  of  a  system  to  verify  programs  written  in  that 
subset.  We  have  shown  that  it  is  possible  to  verify  COBOL  programs,  but 
that  there  are  many  problems  yet  to  be  resolved  to  make  COBOL  verification 
cost-effective.  In  this  report,  we  outline  some  of  these  problems  and, 
in  some  cases,  propose  solutions. 

Program  verification  is  not  yet  applicable  to  the  production  of  soft¬ 
ware.  Although  most  of  the  theoretical  problems  have  been  solved,  tools 
must  be  developed  to  reduce  the  volume  of  material  that  programmers  now 
must  process  in  program  verification.  Among  the  tools  needed  are  well- 
engineered  interactive  aids  and  new  programming  languages. 

In  our  work  we  have: 

(1)  Analyzed  COBOL  with  respect  to  verification. 

(2)  Selected  a  subset  of  COBOL  for  verification. 

(3)  Designed  an  assertion  language  for  formally  describing  the 
intent  of  a  COBOL  program. 

(4)  Designed  a  system  using  the  INTERLISP  language  for  generating 
verification  conditions  for  COBOL  programs. 

(5)  Discussed  the  implications  of  structured  programming  on  COBOL 
verification. 

(6)  Presented  an  example  of  a  verified  COBOL  program  of  modest  size 
(<100  lines  in  the  PROCEDURE  DIVISION). 

In  this  section,  we  discuss  the  goals  and  background  of  the  project, 
the  theory  of  program  verification,  the  programs  verification  for  "real" 
languages,  and  the  structure  of  COBOL. 

In  Section  II,  we  present  a  detailed  analysis  of  COBOL  in  relation 
to  program  verification,  including  general  comments  about  including  or 
excluding  particular  language  features  in  the  COBOL  subset  for  verification 
(hereinafter  called  the  CSV). 

In  Section  III,  we  describe  the  structure  of  the  verification  system 
designed  for  this  project. 

In  Section  IV,  we  formally  describe  the  syntax  of  the  CSV. 


In  Section  V,  we  describe  the  assertion  language  and  some  rules  of 
inference  for  deduction. 

In  Section  VI,  we  describe  the  semantics  of  the  CSV. 

In  Section  VIII,  we  present  an  example  of  a  fully  verified  COBOL  program. 

In  Section  IX,  we  state  the  conclusions  of  the  project. 

The  documented  code  for  the  programs  that  we  have  designed  to  assist 
in  COBOL  verification  is  in  the  Appendix. 


B.  Background  and  Project  Goals 

The  goal  of  program  veri  fication—  "verification”  throughout  this 
report  refers  to  formal  mathematical  proof —  is  to  make  programs  more 
reliable.  In  our  work,  we  make  several  assumptions.  First,  a  programming 
language  is  a  formal  medium  for  expressing  solutions  to  certain  types  of 
problems.  Because  of  this  formality,  a  program  can  be  analyzed  logically. 
Second,  a  program  (especially  a  large  one)  is  not  necessarily  a  good 
medium  for  stating  the  problem  to  be  solved.  A  program  states  how  a 
problem  is  to  be  solved,  not  what  the  problem  is. 


Program  verification  is  not  yet  a  viable  tool  to  improve  software 
reliability  because: 

(1)  The  programs  are  too  complex. 

(2)  The  assertions  are  too  complex. 

(3)  The  programs  have  been  written  in  a  programming  language  that 
is  not  amenable  to  formal  description. 

1,2 

The  means  of  solving  the  first  two  problems  is  that  of  structuring. 

The  primary  goal  of  the  work  described  in  this  report  is  to  solve  the 
third  problem.  The  other  two  issues  are  discussed  in  this  report,  but 
not  emphasized. 


Even  though  program  verification  may  be  difficult,  we  believe  that 
its  usefulness  can  be  increased  to  approach  acceptable  limits.  The 
answer  lies  in  the  seriousness  of  the  software  problem  and  in  its  inherent 
nature.  Almost  every  nontrivial  program  has  some  logical  flaw;  many 
commercial  programs  have  so  many  'bugs”  that  they  do  not  provide  the 
service  promised  by  the  vendor.  Some  programs  contain  undetected  but 
potentially  damaging  errors  even  after  being  tested  and  debugged  for 


some  time. 


The  inherent  nature  of  the  problem  is  that  informal  standards 
(Engl ish-language  specif ications)  cannot  be  used  to  guarantee  the  correctness 
of  a  program.  As  the  technology  matures,  some  formal  notation  is  usually 
developed  so  that  standards  can  be  stated  unambiguously  and  the  product 
can  be  checked  systematically  against  its  standards.  A  doctor’s  pre¬ 
scription  is  a  simple  example  of  such  a  formal  medium  that  is  typically 
not  checked.  Whether  or  not  this  checking  is  done  in  every  case  is 
usually  a  matter  of  cost-effectiveness. 

The  same  thing  is  true  for  program  verification.  We  must  develop  an 
unambiguous  language  for  stating  standards  (i.e.,  an  assertion  language) 
and  techniques  for  systematic  checking  (i.e.,  formal  verification).  We 
can  then  imagine  a  scenario  in  which  assertions  are  written  out,  but  might 
or  might  not  be  formally  checked  against  the  program,  depending  on  cost- 
effectiveness.  But  at  least  some  checking  mechanism  exists,  so  that  if 
the  application  is  critical,  the  cost  can  be  incurred.  Thus,  it  is 
useful  to  do  research  in  verification  techniques  and  to  write  assertions 
for  programs,  even  if  verification  is  not  attempted.  An  added  benefit 
of  this  research  is  to  distinguish  language  features  that  simplify 
analysis  of  programs,  even  if  that  analysis  stops  short  of  proof. 

This  work  is  an  attempt  (the  first  that  we  know  of)  to  apply 
formal  verification  techniques  to  COBOL.  It  is  also  one  of  the  few 
attempts  to  use  verification  techniques  for  any  of  the  commonly  used 
languages . 

C .  Program  Verification — Theory 

The  idea  of  program  verification  goes  back  almost  as  far  as 

3 

programming  itself:  it  was  first  discussed  by  von  Neumann  and  Goldstine. 

The  basic  idea  is  that  there  is  a  state  that  models  some  external 
phenomenon  (e.g.,  differential  equations,  matrices,  payroll  records). 

The  state  can  be  represented  by  the  contents  of  core  memory,  the  contents 
of  files,  or  program  variables  (at  a  more  abstract  level).  There  is  also 
a  set  of  elementary  operations  that  change  the  state.  Examples  of 
elementary  operations  are  machine  instructions  or  statements  in  higher- 
level  programming  languages.  A  program  defines  a  (possibly  infinite) 
set  of  sequences  of  elementary  operations.  When  a  program  is  executed, 
only  one  sequence  of  elementary  operations  is  performed.  The  selection 


of  one  sequence  out  of  the  set  of  sequences  defined  by  the  program  is 
determined  by  the  state  just  before  the  program  is  executed  called  the 
"initial  state."  Thus,  a  program  is  a  function  from  states  to  sequences 
of  operations.  If  the  program  terminates,  the  state  just  after  termination 
is  called  the  "final  state." 

The  user  of  a  program  is  interested  in  knowing  what  the  final  state 

will  be'  for  a  given  initial  state  of  the  program.  Ideally,  he  will  have 

a  specification,  which  expresses  a  mapping  from  initial  states  to  final 

states.  It  is  not  immediately  obvious  whether  a  program  (also  a  mapping 

from  states  to  states)  is  consistent  with  the  specification.  Consistency 

between  a  specification  and  a  program  is  often  called  "program  correctness." 

Program  verification  is  a  set  of  techniques  for  proving  this  consistency. 

4  5 

Flovd  and  Naur  first  described  this  method  of  verification.  The  specifica¬ 
tion  consists  of  a  statement  of  the  properties  that  the  initial  state  must 
have  (the  input  assertion),  and  a  statement  of  the  relation  between  the 
initial  state  and  the  final  state  (the  output  assertion).  Both  input  and 
output  assertions  are  stated  as  logical  predicates. 

The  effects  of  each  of  the  elementary  operations  on  the  state  must 
also  be  formally  described  (input  and  output  assertions  for  these  operations 
are  useful  for  this  purpose).  The  control  operations,  which  do  not  in 
themselves  affect  the  state,  must  also  be  axiomatized.  A  program  may  in 
a  small  number  of  statements  describe  a  large  (possibly  infinite)  sequence 
ol  operations.  To  achieve  verification,  inductive  assertions,  which  break 
the  program's  flowchart  up  into  finite  sequences  of  operations,  must  be 
associated  wi th  each  of  the  loops  of  the  program. 

Floyd's  method  is  used  for  proving  partial  correctness  of  programs. 

A  partially  correct  program  is  consistent  with  its  assertions  only  if  it 
terminates.  Termination  of  a  program  can  be  proved  separately.  Given 
input  and  output  assertions,  program  text  (with  inductive  assertions),  and 
the  definition  of  the  elementary  operations,  a  set  of  formulas  in  first- 
order  logic  can  be  constructed  whose  validity  is  equivalent  to  the  partial 
correctness  of  the  program.  These  formulas  are  called  "verification 
conditions.  A  software  system  that  accepts  as  input  the  program  to  be 
verified  (with  input,  output,  and  inductive  assertions)  is  called  a 
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Verification  conditions  can  be 
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verification  condition  generator."  ' 
proved  by  hand,  or  can  be  input  to  a  deductive  system  or  automatic  theorem 
prover,  which  attempts  to  generate  a  proof.  In  general,  deductive  systems 
are  inadequate  for  proving  verification  conditions  by  completely  automatic 
means,  and  many  systems  are  equipped  with  interactive  facilities  to  allow 
users  to  guide  the  proof.  Deductive  systems  with  interactive  facilities 
are  also  called  "semiautomatic  verification  systems."  A  diagram  of  a 
program  verification  system  is  shown  in  Figure  1-1. 

The  application  of  formal  techniques  to  a  particular  programming 
language  environment  is  often  a  matter  of  style.  The  verification 
condition  generator  incorporates  most  of  the  language-dependent  features, 
because  it  must  translate  assertions  and  statements  in  the  programming 
language  into  expressions  in  predicate  calculus.  Some  verification 
condition  generators  are  based  on  a  particular  semantic  description  of  a 
language.  For  example,  a  verification  condition  generator  for  PASCAL 
(London,  Luckham,  and  Igarashi7)  is  based  on  the  axiomatic  description  of 
PASCAL  by  Hoare  and  Wirth.8 

Several  issues  have  not  been  addressed  by  the  mainstream  of  program 
verification:  The  first  issue,  termination,  has  been  addressed  by 
several  researchers.®’®’ It  can  be  treated  either  with  or  separately 
from  the  issue  of  partial  correctness.  I t  is  important  to  formalize  two 
other  issues  —  run-time  errors  and  validity  of  input  data  —  if 
verification  is  to  lead  to  software  reliability.  All  three  of  these 
issues  have  been  grouped,  to  some  extent,  into  a  property  called  "clean 
termination."^  Although  these  issues  are  important,  they  arc  not  considered 
during  this  work,  which  limits  itself  to  the  basic  issues  of  partial 
correctness  for  COBOL  programs. 

D.  Program  Verification  for  "Real  Languages" 

In  this  subsection,  we  attempt  to  define  the  concept  of  a  real 
programming  language  by  enumerating  some  of  its  properties.  Particularly 
important  are  the  properties  of  semantic  cleanliness  and  syntactic  size 
of  real  languages.  We  also  describe  some  special  properties  of  programs 
for  which  proof  is  particularly  important  when  dealing  with  real  languages. 
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COBOL  is  a  member  of  the  set  of  "real"  programming  languages,  which 
are  those  that  are  widely  used  in  many  applications  and  for  which  standards 
exist.  Real  languages  are  usually,  but  not  always,  commercially  viable 
products.  Examples  of  real  languages  are  COBOL,  FORTRAN,  PL/ I  ,  and  (to  a 
lesser  extent)  Algol  and  LISP.  The  properties  that  make  a  programming 
language  a  real  language  unfortunately  also  detract  from  the  ease  of 
verifying  programs  in  that  language.  Most  of  these  undesirable  properties 
can  be  summed  under  the  term  "lack  of  semantic  cleanliness." 

The  semantics  of  a  programming  language  describe  the  meaning  of 
statements  in  the  language,  expressed  in  some  well-defined  formal  medium. 

A  language  has  "clean"  semantics  if  the  definition  of  the  language  is 
elegantly  expressible  in  some  formal  medium.  There  are  many  good  reasons 
why  real  languages  are  not  semantically  cleans 

.  Most  real  languages  have  many  operations.  A  real  language 
incorporates  the  special  interests  of  many  groups  of  users, 
whose  interests  are  not  always  compatible.  Large  numbers  of 
features  must  often  be  added.  These  features  not  only 
complicate  the  semantics  of  the  language,  but  often  violate 
the  spirit  that  motivated  the  initial  conception  of  the  language. 
PL/I  is  a  good  example  of  that.  In  a  desire  to  overcome  some  of 
the  difficulties  of  FORTRAN,  COBOL,  and  Algol,  the  designers  of 
PL/I  created  something  larger  than  any  of  its  ancestors.  Con¬ 
sidered  alone,  the  size  of  real  languages  is  a  major  obstacle 
to  verification. 

.  Most  real  languages  concede  syntactic  generality  in  the  interest 
of  an  efficient  implementation,  in  either  the  compiler  or  the 
generated  code.  Examples  of  these  dependencies  are  limitations 
in  the  number  of  nestings  (COBOL)  or  in  the  complexity  of  an 
arithmetic  expression  in  certain  syntactic  positions  (FORTRAN). 

.  Most  real  languages  must  have  some  features  that  deal  with  the 
hardware  or  operating  system.  The  ENVIRONMENT  DIVISION  and 
Communication  Module  of  COBOL  are  examples  of  these  features. 
Standardization  has  served  as  a  uniform  interface  between  the 
language  and  the  environment.  However,  the  fact  that  a  variable 
is  SYNCHRONIZED  or  that  there  are  100  logical  records  in  a  physical 
record  will  not  affect  the  correctness  of  a  COBOL  program,  but  may 
affect  the  performance  of  that  program. 

.  Most  real  languages  are  the  products  of  an  evolving  development, 
as  illustrated  by  the  fact  that  many  real  languages  have  numbers 
after  their  names  to  indicate  the  particular  dialect  in  the 
sequence  (COBOL  74,  FORTRAN  IV,  Algol  60,  LISP  1.5).  In  many 
cases,  there  is  a  desire  for  upward  compatibility,  so  that  bad 
features  that  could  have  been  eliminated  remain —  augmented  by 
the  improvements. 
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Most  of  the  important  languages  wore  created  before  the  aesthetics 

of  programming  were  well  established.  Thus,  many  real  languages  lack 

features  such  as  strong  typing,  block  structure,  and  flexible  procedure 

and  macro  facilities.  Structured  programming  practices  are  motivated  by 

a  desire  to  infuse  these  new  aesthetics  into  the  programming  world.  Perhaps 

verification  will  generate  its  own  set  of  aesthetics  to  guide  the  design 

of  future  programming  languages.  Finally  there  is  the  problem  that  even 

if  the  semantics  of  a  real  language  are  clean,  they  are  usually  stated  in 
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natural  language,  e.g.,  in  a  standards  manual.  A  standards  manual  may 

suffice  for  programmers  and  language  implementers,  but  it  is  not  directly 

applicable  to  verification.  Some  attempts  have  been  made  to  define 
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language  semantics  formally  (e.g.,  VDL  for  PL/I).  However,  as  long  as 
there  are  no  formal  semantics  for  COBOL,  it  will  be  impossible  to  prove 
the  correspondence  between  a  language  that  is  verified  and  a  compiled 
version  of  such  a  language. 

Before  solutions  to  the  problems  of  semantic  cleanliness  are  con¬ 
sidered,  there  is  one  major  constraint  to  these  solutions:  the  solutions 
must  have  minimum  effect  on  the  languages  themselves.  There  is  pn  under¬ 
standable  resistance  by  manufacturers  to  redesigning  the  programming 
languages  that  they  support,  and  a  similarly  understandable  resistance 
by  users  to  recoding  the  software  that  they  have  written.  Thus,  the 
solution  to  the  verification  problem  for  real  languages  must  be  incremental. 
Research  in  new  languages  that  support  verification  is  very  important, 
but  the  data  processing  community  will  ignore  this  research  unless 
verification  can  be  shown  to  be  useful  for  currently  existing  languages. 

The  problem  of  language  size  has  two  aspects;  syntactic  and 
semantic.  When  a  language  has  syntactic  complexity  (e.g.,  COBOL),  there 
are  many  different  ways  to  do  the  same  thing.  When  a  language  has 
semantic  complexity,  there  are  many  things  that  can  be  done.  In  cases 
where  syntactic  complexity  exists,  verification  can  be  done  on  a  program 
written  in  an  internal  form  that  is  syntactically  simple — there  is  only 
one  way  to  do  any  given  thing.  Automatic  translation  from  the  external 
form  to  the  internal  form  is  relatively  straightforward.  Semantic  com¬ 
plexity  is  handled  piimarily  by  subsetting,  which  entails  choosing  a 
sublanguage  that  includes  only  the  desired  semantic  features.  Some  lan¬ 
guage  cons  tructs  are  useful  (and  even  necessary),  but  can  easily  be  misused. 
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This  is  precisely  the  problem  with  the  GO  TO.  The  solution  to  this  type 
of  problem  takes  several  forms : 

(1)  Change  the  language. 

(2)  Establish  management  techniques  to  prevent  abuse  of  the 
construct. 

(3)  Develop  a  preprocessor  for  the  language  that  will  allow 
desirable  constructs  in  place  of  harmful  ones. 

For  more  information  concerning  these  alternatives  as  applied  to 
COBOL,  see  Section  VII  on  structured  programming  and  COBOL. 

The  semantics  of  a  language  can  be  specified  by  formulating  an  abstract 
machine  whose  instruction  set  is  the  set  of  commands  in  the  programming 
language.  Thus,  a  formal  description  of  a  language  is  the  definition  of 
such  a  machine.  We  define  a  machine  that  executes  a  subset  of  COBOL  pro¬ 
grams  by  means  of  a  set  of  rules  for  generating  verification  conditions 
for  the  programs.  Assuming  that  such  a  machine  is  actually  consistent 
with  a  given  COBOL  compiler  (something  that  may  be  difficult  to  determine), 
a  program  that  is  proved  correct — using  this  verification  condition  gnerator- 
will  actually  run  correctly  when  compiled  by  the  given  compiler.  We  use 

informal  arguments  to  show  that  our  formal  definition  of  a  COBOL  subset  is 
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consistent  with  the  ANSI  standard. 

With  regard  to  the  features  of  a  real  language  that  are  dependent  on 
the  hardware  or  the  operating  system,  there  are  two  strategies:  to  exclude 
them  or  to  axiomatize  them.  Statements  in  COBOL's  ENVIRONMENT  DIVISION  and 
items  such  as  SYNCHRONIZED  or  the  number  of  logical  records  per  block  can 
be  excluded  since  they  do  not  affect  the  outcome  of  the  program.  Special 
kinds  of  file  input/output  and  communication  with  the  operating  system  can 
be-  axiomatized  as  properties  of  the  abstract  machine  that  defines  the  pro¬ 
gramming  language. 

Several  kinds  of  program  properties  are  particularly  important  for 
real  languages.  There  has  been  very  little  research  done  to  date  in  the 
statement  and  proof  of  these  kinds  of  properties.  They  are: 

(1)  Finite  machine  arithmetic 

(2)  Clean  termination  and  run-time  errors 

(3)  Validity  of  input  data. 
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The  issue  of  finite  machine  arithmetic  is  particularly  acute  in 
COBOL  because  data  items  have  no  more  digits  than  they  need  for  internal 
storage,  while  other  languages  have  the  (relatively  large)  word  size  of 
the  machine.  Thus,  overflow  and  truncation  occur  often  enough  to  be  of 
concern.  We  consider  these  items  in  Section  VI. 

Clean  termination  was  described  earlier  in  this  section.  Because 
of  the  limited  scope  of  this  project,  we  did  not  deal  with  this  issue 
in  this  report.  Clean  termination  assumes  the  absence  of  run-time  errors. 
However,  such  assumptions  cannot  safely  be  made,  as  is  the  case  in  hard¬ 
ware  and  operating  system  errors  and  in  situations  where  input  data  is 
invalid.  Run-time  errors  should  be  considered  in  e f forts  to  verify  pro¬ 
grams  in  real  language. 

In  verification,  input  data  is  assumed  to  be  valid  (with  respect  to 
type  and  range  of  values).  One  of  the  greatest  difficulties  in  guaranteeing 
the  reliability  of  programs  in  real  languages  is  that  such  assumptions  cannot 
be  made.  In  other  words,  input  data  items  are  frequently  faulty,  and  programs 
must  be  written  to  account  for  such  situations.  A  real  program  will  typically 
have  several  degraded  modes  of  performance  (without  aborting  the  program), 
depending  on  the  severity  of  the  error.  For  example,  even  if  a  single 
record  is  destroyed,  all  other  records  may  be  processed  correctly.  There 
is  a  need  in  program  verification  to  anticipate  such  occurrences  and  to 
make  the  input  assertions  for  these  programs  as  weak  as  possible. 

E.  Brief  Discuss  ion  of  the  COBOL  Language 

COBOL  is  an  extremely  complex  language — both  syntactically  and  seman¬ 
tically.  Since  we  could  only  apply  verification  techniques  to  a  small  subset 
of  the  entire  language,  we  had  to  choose  the  issues  (and  parts  of  the  lan¬ 
guage)  that  represent  the  most  important  aspects  of  COBOL.  After  briefly 
describing  some  characteristics  of  the  COBOL  language,  we  outline  the 
coverage  of  features  in  the  COBOL  subset  chosen  by  us  relative  to  the  mod¬ 
ularization  of  ANS  COBOL. 

COBOL  has  a  rich  set  of  data  types  and  operations.  The  area  of  most 
immediate  concern  for  verification  is  called  the  'elementary  data  item." 


All  computation  in  COBOL  is  character-oriented.  Even  numeric  data  items 
are  treated  as  character  strings  with  respect  to  assignment,  truncation, 
and  editing.  Its  control  statements  are  also  interesting,  if  not  elegant 


to  formalize.  Elementary  data  items  form  the  leaves  in  a  tree-structured 
data  declaration,  of  which  the  nonleaf  nodes  are  called  "group  data  items." 

A  record  is  an  entire  tree  of  data  declarations. 

Input/output  is  very  important  in  COBOL.  Many  programs  follow  the 
scheme : 

Open  files,  initialize; 

LOOP:  Read  input  at  end  go  to  CLEANUP; 

Process  data; 

Write  output; 

go  to  LOOP; 

CLEANUP:  Close  files,  etc.; 

Thus,  no  useful  COBOL  program  can  be  proved  correct  without  some  axiomati- 
zation  of  input/output. 
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Full  ANS  COBOL  is  one  of  the  most  complicated  programming  languages, 
containing  features  that  range  from  strings  to  interprocess  communication. 
Thus,  the  subset  of  COBOL  that  we  are  verifying  is  small  relative  to  the 
entire  language,  although  the  subset  is  a  powerful  language  in  itself.  The 
subset  provides  arithmetic  and  relational  operations  on  COBOL  numeric  data 
items,  generalized  control  structures,  and  sequential  input/output.  A  dia¬ 
gram  of  the  components  of  the  entire  ANS  COBOL  language  is  shown  in  Figure  1-2 
In  Figure  1-2  ,  we  indicate  the  parts  of  the  language  handled  by  the  current 
verification  system.  The  language  is  divided  into  twelve  modules ,  which  group 
related  sets  of  features,  and  three  levels ,  which  are  successively  more  sophis 
ticated  subsets  of  the  modules. 

A  brief  description  of  the  contents  of  each  module  follows: 

(1)  Nucleus — Basic  language  constructs:  control  structures, 
data  items. 

(2)  Table  Handling — Arrays  and  subscripting. 

(3)  Sequential  I/O — Reads  and  writes  sequential  files;  a 
sequential  file  is  a  file  whose  records  must  be  read  in 
the  order  that  they  were  written. 

(4)  Relative  I/0--Reads  from  and  writes  to  files  whose  records 
can  be  accessed  in  either  sequential  or  random  order,  via 
a  unique  key  that  specifies  a  record's  ordinal  position 


within  the  file 


FIGURE  1-2  STRUCTURE  OF  THE  COBOL  LANGUAGE 


(5)  Indexed  I/O — Like  relative  I/O,  except  there  can  be 
multiple  keys  per  record  and  a  user  can  choose  an 
arbitrary  key  when  the  record  is  written. 

(6)  Sort-Merge — Sorts  a  file  according  to  fields  within  its 
records,  or  merges  two  or  more  identically  sorted  files 
of  similar  record  structure. 

(7)  Report  Writer — Allows  the  programmer  to  generate  a 
file  consisting  of  report  (lineprinter)  records  solely 
by  specifying  the  format  of  the  report,  rather  than  the 
algorithm  for  generating  the  report. 

(8)  Segmentation — Allows  the  programmer  to  specify  the  divi- 
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sion  of  a  COBOL  program  into  segments  whose  object  code 
can  be  overlayed  in  memory. 

(9)  Library — Enables  the  copying  of  sections  of  source  code 
from  centralized  libraries. 

(10)  Debug — Allows  the  insertion  of  special  sections  of  code 
for  debugging,  the  execution  of  which  can  be  switched  on 
and  off  by  compile-  or  object- time  switches. 

(11)  Interprogram  Communication — External  procedure  call  and 
data-sharing  mechanism. 

(12)  Communication — Message  and  synchronization  facilities  for 
concurrently  executing  programs. 

The  levels  are  numbered  from  1  to  3,  in  order  of  increasing  complexity. 

Most  modules  have  no  features  at  Level  1,  as  Figure  1-2  indicates. 

As  shown  in  Figure  1-2,  our  subset  of  COBOL  provides  most  of  the 
features  of  Level  1  and  some  features  of  Level  2,  in  the  Nucleus,  Table 
Handling,  and  Sequential  I/O  Modules.  Most  of  the  features  left  out 
(e.g. ,  ALTER)  are  those  that  we  consider  undesirable  because  they  sub¬ 
stantially  increase  the  difficulty  of  verification.  Future  work  should 
expand  the  subset  to  include  most  of  Level  2  in  the  aforementioned  modules, 
and  perhaps  Level  2  of  modules  such  as  Relative  and  Indexed  I/O.  We  view 
modules  such  as  Library  and  Interprogram  Communication  as  also  being  straight¬ 
forward  to  verify,  and  modules  such  as  Segmen tat  ion  as  not  greatly  affecting 
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a  program’s  input/output  behavior.  However,  we  view  the  Debug,  Sort- 
Merge,  and  Communication  Modules  as  being  extremely  difficult  to  verify, 
and  as  being  of  secondary  importance  at  present. 

There  is  a  tendency  to  structure  large  COBOL  programs  around  a  large 

data  base  that  has  a  unified  set  of  data  declarations  that  can  be  used  by 
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many  programs.  This  is  the  aim  of  the  CODASYL  report  on  data  bases,  in 
which  the  global  data  declarations  for  the  whole  system  are  called  "schemas” 
and  the  local  declarations  for  individual  programs  are  called  "subschemas." 
Although  we  have  not  looked  at  this  report  in  depth,  we  find  that  the 
CODASYL  report  allows  almost  the  same  data  declarations  as  COBOL  74  and 
permits  almost  arbitrary  programs  in  COBOL  74  to  operate  on  the  shared 
data.  Thus,  we  can  use  the  same  subsetting  restrictions  in  the  declarations 
and  programs  Jor  the  data  base  environment  as  we  use  for  regular  COBOL 
programs.  We  think  that  the  problem  of  COBOL  programs  in  cooperation  can 
be  better  approached  if  the  programs  are  forced  to  have  consistent  data 
declarations.  Thus,  the  CODASYL  work  can  by  itself  improve  the  reliability 
of  large  COBOL  systems  and  be  consistent  with  our  effort  in  formally  veri¬ 
fying  COBOL  programs. 
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II  ANALYSIS  OF  COBOL  WITH  RESPECT  TO  VERIFICATION 


A .  Introduction 

In  this  section  we  present  a  general  analysis  of  COBOL  for  applicabil¬ 
ity  of  verification  techniques.  We  try  to  identify  some  important  general 
issues  in  COBOL  that  may  have  an  impact  on  verification  to  be  prepared  for 
specific  work,  such  as  choosing  a  subset  (Section  IV)  or  designing  the 
verification  system  (Section  III).  This  discussion  is  different  in  that 
most  literature  on  COBOL  does  not  address  formal  verification. 

If  one  considers  a  COBOL  program  to  be  running  on  a  formally  defined 
abstract  machine  that  runs  only  COBOL  programs,  then  one  can  try  to  formally 
define  that  abstract  machine.  If  one  encounters  language  constructs  that 
are  difficult  to  formally  define  and  that  lead  to  a  needlessly  complex 
definition,  programs  written  in  such  a  language  will  be  difficult  to  verify. 
Often  one  must  simplify  the  real  COBOL  language  by  subsetting  it,  so  as 
to  attain  a  tractable  formal  definition.  Our  analysis  is  based  on  such 
criteria.  Inelegances  in  the  formal  definition  can  result  (1)  from 
machine-dependencies  and  representation  issues  that  violate  the  level  of 
abstraction  intended  to  be  provided  by  a  COBOL  machine,  (2)  from  a  multi¬ 
plicity  of  special  cases  that  must  all  be  accounted  for  or  (3)  from  con¬ 
structs  that  are  too  general  to  allow  powerful  proof  procedures  to  be 
applied . 

Our  analysis  is  based  on  two  dimensions  of  the  language--the  data 
structures  and  the  verbs.  The  interesting  aspects  of  COBOL  are  charac¬ 
terized  in  these  two  dimensions.  Data  structures  of  COBOL  are  divided 
in  these  categories: 

(1)  Elementary  data  items  with  interesting  properties 

(2)  Tree  structured  records  and  arrays  of  data  declarations 

(3)  Files  consisting  of  many  records 

(4)  Multiple  data  declarations  for  the  same  storage  areas. 

Verbs  of  COBOL  are  divided  into  these  categories: 

(1)  Assignment  statements 

(2)  Control  statements 

(3)  Input/output  statements. 
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B.  Elementary  Data  Items 

Elementary  (nonaggregate)  data  items  can  be  either  DISPLAY  (a  string 
of  characters)  or  COMPUTATIONAL  (a  string  of  bits,  e.g.,  machine  integers 
and  floating-point  numbers).  We  decided  to  consider  only  DISPLAY  data 
items--since  COBOL's  major  application  is  to  manipulate  character-oriented 
data.  DISPLAY  items  are  characterized  by  a  PICTURE  specification  (e.g., 
AAA,  XXX,  or  S999V999) ,  which  is  a  format  statement  for  representing  the 
data  item.  A  PICTURE  specification  implicitly  declares  the  type  of  the 
data  item  to  be  one  of  the  following:  ALPHABETIC,  NUMERTC  ALPHANUMERIC, 
NUMERIC  EDITED,  or  ALPHANUMERIC  EDITED.  The  EDITED  data  items  are  those 
whose  values  must  be  processed  to  be  printed  in  a  special  format.  The 
PICTURE  specification  also  describes  the  size  of  the  data  item,  its  sign, 
and  the  position  of  its  decimal  point.  The  PICTURE  specification  relates 
to  the  possible  values  that  a  data  item  can  assume  so  that  a  two-digit 
integer,  for  example,  (PICTURE  specification  99),  has  a  maximum  value 
of  99.  In  FORTRAN,  on  the  other  hand,  a  data  item  can  only  occupy  the 
standard  amount  of  storage  space  for  an  object  of  its  type  and  takes 
on  the  same  format  each  time  it  is  printed. 

Our  major  concern  was  with  NUMERIC  data  items,  for  two  reasons: 

(1)  These  items  are  necessary  for  verifying  nontrivial  programs. 

(2)  Something  is  known  about  verifying  programs  in  the  numeric 
domain.  (Domains  such  as  strings  have  had  little  explora¬ 
tion  .  ) 

Originally,  we  had  hoped  to  cover  both  NUMERIC  and  NUMERIC  EDITED  items, 
but  the  handling  of  NUMERIC  EDITED  items  turned  out  to  be  too  compli¬ 
cated  to  be  handled  in  the  allotted  time. 

Although  a  NUMERIC  data  item  in  COBOL  is  a  character  string,  in 
most  cases  we  consider  the  real  numeric  value  that  the  data  item  repre¬ 
sents.  The  only  time  we  consider  a  NUMERIC  data  item's  character  string 
representation  or  PICTURE  specification  is  in  assignment  statements  and 
arithmetic  operations,  since  truncation  and  overflow  can  occur  there. 
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c. 


Tree-Structured  Records 


The  "elementary  items"  are  the  leaves  of  the  tree-structured  record 
declarations  of  the  COBOL  DATA  DIVISION.  The  nonleaf  nodes  of  the  tree 
are  called  "group  data  items."  All  data  items  in  the  tree  have  "level 
numbers"  associated  with  them.  For  example,  in  the  data  declaration 
scheme 


01  A 

02  B 
02  C 

03  D 
02  E 

03  F 
03  G, 

B,  D,  F,  and  G  are  elementary  items;  A,  C,  and  E  are  group  data  items; 
and  01,  02,  and  03  are  level  numbers. 

There  are  several  implications  of  the  tree-structure,  all  following 
from  the  fact  that  each  data  item  has  a  context  (i.e.,  its  sequence  of 
ancestors  in  the  declaration  tree).  This  allows  lower-level  data  items  to 
be  referred  to  by  naming  an  ancestor  (e.g.,  in  the  MOVE  and  MOVE 
CORRESPONDING  statements).  It  also  allows  two  or  more  different  data 
items  to  have  the  same  name,  so  long  as  their  contexts  can  be  distin¬ 
guished  by  qualification.  For  example,  the  data  declaration  scheme 

01  A 

02  B 
02  D 

01  C 

02  B 
02  E 

allows  references  to  the  two  different  data  items  ”B  IN  A"  and  "B  IN  C- " 

A  data  item  can  have  as  many  qualifiers  as  are  needed  to  ensure 
uniqueness.  We  handle  qualification  in  the  CSV  (COBOL  Subset  for 
Verification) . 

Arrays  can  also  be  considered  as  group  data  items  whose  constituents  are 
referenced  in  a  special  way.  For  example,  an  array  A  with  12  elements 
is  declared  as  follows: 

02  A  PICTURE  999  OCCURS  12  TIMES. 


An  array  element  is  referenced  as  in  FORTRAN  (e.g.,  A  ( I ) ) . 


D. 


Files 


Files  are  the  'lost  macroscopic  data  structures  manipulated  by  COBOL 
programs.  In  fact,  the  behavior  of  a  COBOL  program  can  be  described  by 
stating  properties  of  the  input  and  output  files  manipulated  by  the  pro¬ 
gram.  Thus,  files  are  not  Just  another  feature  of  the  language,  but 
essential  elements.  To  deal  with  the  semantics  of  COBOL,  we  must  include 
files  . 

Files  in  COBOL  are  structures  of  records  Sequential  files  are  a 
sequence  of  records.  Writing  a  sequential  file  adds  a  record  onto  the 
sequence.  To  read  a  sequential  file,  a  program  starts  by  accessing  the 
first  record  of  the  sequence.  Subsequent  rerd  operations  access  the  next 
record  in  the  sequence,  and  so  on.  Direct  access  (relative)  files  and 
indexed  sequential  files  are  structures  o  files  that  can  be  referenced 
either  sequentially  (in  an  implicit  way)  or  by  key  (in  an  explicit  way). 

A  record  of  a  direct  access  file  has  one  key  that  corresponds  to  its 
relative  position  within  the  file.  A  record  of  an  indexed  sequential 
file  can  have  several  keys  that  are  independent  of  the  record's  relative 
location  within  the  file. 

We  consider  only  sequential  files  in  this  phase  of  the  project. 

These  files  are  axiomatized  as  arrays  of  records.  F.aoh  array  has  two 
variables:  one  indicates  the  length  of  the  file  and  one  poi:.  to  the 
most  recently  accessed  record.  We  foresee  a  straightforward 
axiomatization  of  relative  and  indexed  files  in  the  next  phase  of  the 
project . 

E.  Multiple  Definition  of  Storage  Areas 

In  addition  to  providing  a  facility  for  the  management  of  variables, 
COBOL  also  allows  the  programmer  to  use  multiple  definitions  for  the  same 
areas  of  storage--similar  to  the  FORTRAN  COMMON  or  EQUIVALENCE  statements. 
However,  COBOL  data  items  can  be  of  arbitrary  size,  whereas  FORTRAN  data 
items  come  in  fixed  sizes  related  to  the  machine  word.  The  biggest  danger 
in  multiple  definition  of  storage  areas  is  that  a  well-defined  change  to 
a  data  item  defined  in  a  certain  way  may  cause  an  ill-defined  (or  possibly 
undefined)  change  to  a  data  item  that  is  defined  differently  but  shares 
the  same  storage  area.  This  possibility  destroys  the  level  of  abstraction 
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that  is  guaranteed  by  the  concept  of  a  data  item  in  a  higher  level  language. 
This  level  of  abstraction  is  sometimes  confused  with  the  lower  level  abstrac 
tlon  of  the  machine's  representation  for  the  data  item.  Since  higher  level 
languages  were  created  to  avoid  machine  representations,  overlapping  data 
definitions  circumvent  a  major  purpose  of  a  higher  level  language.  However, 
overlapping  data  definitions  improve  the  efficiency  of  prop-ams  written 
in  COBOL — even  if  they  detract  from  their  reliability. 

COBOL  provides  three  types  of  multiple  data  definition  facilities: 
multiple  records  for  a  file,  REDEFINES,  and  RENAMES.  The  first  two 
facilities  are  similar.  In  both  cases,  a  string  of  characters  that  belong 
to  a  data  item  (either  group  or  elementary)  can  have  another  data  definition 
The  primitive  notion  is  that  of  a  character.  An  example  of  REDEFINES  is: 

02  A. 

03  B  PICTURE  999. 

03  C  PICTURE  S999 . 

02  AA  REDEFINES  A. 

03  BC  PICTURE  XXXXXX. 

A  graphical  description  of  this  data  declaration  occurs  in  Figure  II-l. 

Note  that  assignment  to  B  or  C  can  change  the  value  of  BC ,  and  vice  versa. 

Note  that  any  assignment  to  B  or  C  will  cause  a  valid  assignment  to  BC , 

depending  on  the  machine-dependent  convention  for  representing  the  sign  in 

C.  However,  there  are  many  assignments  to  BC  that  would  cause  invalid 

values  for  either  B  or  C.  Multiple  records  per  file  are  nothing  more 
than  a  redefinition  at  the  top  level  of  the  data  declaration  tree. 

RENAMES  is  slightly  different  as  shown  in  this  example: 

02  A. 

03  B  PICTURE  99. 

03  C  PICTURE  999. 

02  D. 

03  E  PICTURE  9999. 

66  X  RENAMES  B  THRU  E. 

This  declaration  is  depicted  in  Figure  II-2.  The  construct  allows  a  new 
group  item  to  be  defined,  possibly  to  overlap  other  group  items.  However, 
the  definitions  of  all  elementary  items  are  left  intact.  RENAMES  preserves 
the  level  of  abstraction  provided  by  a  COBOL  elementary  data  item. 
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FIGURE  11-1  MULTIPLE  DEFINITION  OF  STORAGE 
BY  THE  REDEFINES  STATEMENT 


Data  Declaration  1 


Common  Storage 
(Elementary  Items! 


Data  Declaration  2 
SA-3967-4 


multiple  definition  of  storage  by 

THE  RENAMES  STATEMENT 


We  have  left  RENAMES,  REDEFINES,  and  multiple-records-per-file  out 
of  the  COBOL  subset  in  this  phase  of  the  project.  We  envision  including 
RENAMES  in  some  future  subset  for  verification,  because  it  is  a  formally 
well-behaved  construct.  However,  the  other  two  constructs  present  diffi¬ 
cult  problems  in  the  general  case.  Severe  restrictions  would  be  needed 
for  redefinition  at  the  character  level.  We  would  allow  the  REDEFINES 
statement  when  it  does  not  take  use  of  machine  dependencies  and  underlying 
representation  conventions. 

F .  Assignment  and  Computation  Statements 

These  statements  define  new  values  for  elementary  data  items  in  COBOL. 
Statements  such  as  MOVE  and  MOVE  CORRESPONDING  are  called  "assignment 
statements,"  while  statements  such  as  ADD,  SUBTRACT,  MULTIPLY,  DIVIDE  and 
COMPUTE  are  called  "computation  statements.”  In  Section  II. B,  we  dis¬ 
cussed  how  an  elementary  NUMERIC  item  possesses  both  a  value  and  a  PICTURE 
specification.  Consider  the  statement 

MOVE  A  TO  B. , 

where  A  and  B  are  elementary  data  items.  In  this  type  of  operation, 
truncation  and/or  conversion  may  occur  if  the  data  items  are  of  different 
types . 

For  now  we  have  obviated  the  conversion  problem  by  allowing  only  two 
types  of  data  items--NUMERIC  and  ALPHANUMERIC--with  no  assignment  from 
data  of  one  type  to  data  items  of  the  other.  However,  in  full  COBOL  this 
becomes  a  complex  problem,  with  the  addition  of  NUMERIC  EDITED,  ALPHANUMERIC 
EDITED,  and  ALPHABETIC  type  data  items.  The  set  of  permissible  conversions  is 
described  in  Figure  II-3.  The  permitted  transfers  marked  by  asterisks  can 
violate  the  integrity  of  the  receiving  data  item.  These  items  should  either 
be  prohibited  or  validated  by  run-time  type  checking.  There  might  be  some 
difficulties,  since  COBOL  does  not  perform  this  kind  of  checking  until  an 
error  occurs.  For  example,  use  of  a  numeric  data  item  in  an  arithmetic 
statement  to  which  an  alphanumeric  data  item  has  been  moved,  might  not  be 
possible . 

Truncation  is  the  deletion  of  trailing  or  leading  characters  because 
of  an  incompatibility  of  the  PICTURE  specifications  of  the  sending  and  the 
receiving  data  items.  With  ALPHANUMERIC  data  items,  tho  rightmost 


FIGURE  11-3  DIAGRAM  OF  PERMISSIBLE  MOVE  OPERATIONS 
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characters  are  always  truncated,  unless  the  receiving  item  is  declared  as 
RIGHT  JUSTIFIED.  If  the  PICTURE  specifications  of  an  ALPHANUMERIC  item 
indicate  that  it  is  too  big  to  fit  t-v.e  sending  item,  spaces  are  filled  in 
on  the  right  (or  left,  when  the  item  is  RIGHT  JUSTIFIED).  In  a  MOVE  state¬ 
ment  among  numeric  data  items,  the  decimal  points  are  first  aligned,  then 
truncation  or  filling  with  zeros  occurs  at  either  end  to  fit  the  receiving 
data  item. 

We  provide  an  assertion-language  function  called  TRUNCATE  (taking  a 
PICTURE  specification  and  a  value  as  arguments)  that  describes  this  operation. 
However,  there  is  some  question  about  allowing  the  widespread  use  of  trunca¬ 
tion  in  COBOL  programs.  We  believe  that  indiscriminate  use  of  truncation 
is  a  major  cause  of  unreliability  in  COBOL  programs.  In  cases  where 
truncation  causes  the  loss  of  insignificant  digits,  this  is  a  comparatively 
minor  occurrence,  although  it  may  cause  trouble.  However,  the  truncation 
of  significant  digits  of  a  data  item,  as  the  result  of  a  MOVE  statement, 
can  cause  serious  problems.  COBOL  was  designed  to  allow  significant  digits 
to  be  truncated  in  a  MOVE  statement.  This  is  a  convenient  way  to  obtain  the 
trailing  digits  in  the  destination  item.  However,  it  is  difficult  to  tell 
whether  that  was  intended  or  accidental,  since  both  intentional 
and  accidental  uses  have  the  same  syntactic  notation.  If  significant 
digit  truncation  were  restricted  to  a  statement  such  as 

MOVE  TRUNCATED  A  TO  B., 

then  the  programmer's  intention  could  be  syntactically  encoded  in  the 
statement . 

Computation  statements  generate  a  SIZE  ERROR  when  results  produce 
overflow  or  truncation  of  significant  digits  (at  run-time).  This  can  be 
handled  explicitly  by  the  programmer  by  specifying  a  sequence  of  statements 
to  be  executed  when  a  SIZE  ERROR  is  detected.  Otherwise  a  run-time  error 
i3  generated. 

The  statement 

MOVE  CORRESPONDING  -source'  TO  cdes t i na t i on> 

take*-  two  group  data  items  as  arguments.  We  define  MOVE  CORRESPONDING 
recursively.  We  determine  the  descendants  of  the  source  item  and  desti¬ 
nation  items,  and  the  intersection  set  of  their  names.  For  each  element 
of  the  intersection  set  whose  source  item  is  elementary,  a  MOVE  is  executed  to 
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the  corresponding  data  item  in  the  destination.  Otherwise,  a  MOVE  CORRE¬ 
SPONDING  is  performed  from  the  source  item  to  the  corresponding  destination 
item  of  the  intersection  set.  This  must  be  handled  in  the  verification 
condition  generator.  The  statement 

MOVE  <source>  to  destination  > 

when  used  on  group  data  items,  indicates  a  moving  of  the  contents  of 
memory  (without  truncation  or  other  processing)  occupied  by  <source>  to 
the  memory  area  occupied  by  destination >.  This  causes  a  loss  of  abstrac¬ 
tion  and  is  not  allowed  in  the  CSV . 

G.  Control  Statements 

Control  statements  in  a  programming  language  relate  the  lexical 
ordering  of  statements  in  a  program  to  the  dynamic  ordering  of  execution 
of  those  program  statements.  A  program  is  a  fixed  sequence  of  statements 
that  defines  the  lexical  ordering.  However,  when  a  program  executes,  the 
dynamic  ordering  of  statements  (the  order  of  execution)  depends  on  the 
input  data.  It  is  a  function  of  the  lexical  ordering  and  of  the  data  upon 
which  the  program  operates.  Several  goals  must  be  attained  in  choosing 
the  set  of  control  statements  to  be  used  in  a  programming  language: 

(1)  Efficient  description  of  any  algorithm,  in  terms  of 
both  time  and  space. 

(2)  Minimum  work  for  the  programmer. 

(3)  Maximum  simplicity  and  understandability  of  the  control 
primitives  themselves. 

(4)  Maximum  understandability  of  the  programs  written  using 
these  control  statements. 

Goal  (1)  is  satisfied  by  GO  TO  and  a  conditional  statement,  such  as  those 
contained  in  any  assembler.  This  goal  conflicts,  to  some  extent,  with  all 
of  the  others.  To  satisfy  Goal  (2),  language  designers  have  introduced 
more  complex  control  statements:  e.g.,  looping  constructs,  procedures  (i.e., 
call  and  return),  case  statements,  coroutines,  signals,  switches,  and  the 
ALTER  statement  (unique  to  COBOL).  Languages  have  resulted  with  a  prolifera¬ 
tion  of  primitives,  some  of  which  seem  to  be  invented  for  a  single  special 
case.  In  regard  to  Goal  (3),  some  work  has  been  done  in  trying  to  find 
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a  minimum  set  of  control  primitives  sufficient  for  most  applications. 

Such  efforts  have  also  concentrated  on  eliminating  the  simplest  but  most 
primitive  control  statements  (e.g.,  the  GO  TO),  in  attempting  to  satisfy 
Goal  (4). 

In  terms  of  verification,  Goals  (3)  and  (4)  are  the  most  desirable. 
However,  in  terms  of  the  COBOL  subset,  Goal  (4)  can  be  ignored,  because 
it  is  always  possible  to  write  an  incomprehensible  (or  difficult  to  verify) 
program  using  any  given  set  of  control  primitives.  Thus,  adherence  to 
Goal  (4)  depends  largely  on  how  the  programs  are  written,  not  on  the  control 
primitives  available.  In  any  case,  the  subset  should  contain  primitives 
that  have  an  easily  describable  semantics. 

At  first  glance,  COBOL  control  statements  seem  to  be  simple,  but 
they  really  contain  much  underlying  complexity--making  verification  a  poten¬ 
tially  difficult  task.  The  basic  unit  of  execution  is  the  statement  or 
sentence.  Sequences  of  statements  are  grouped  together  into  paragraphs 
that  are  named.  Control  statements  in  COBOL  take  one  of  four  schemes: 

(1)  Lexical  ordering,  either  within  or  between  paragraphs, 
which  is  the  default. 

(2)  Unconditional  transfer,  via  the  GO  TO.  The  object  of  a 
GO  TO  is  a  paragraph  name.  Control  resumes  at  the  first 
statement  of  the  paragraph. 

(3)  Conditional  execution,  via  the  "IF  a  b  ELSE  c"  statement. 

Either  statement  b  or  c  is  executed,  depending  on  the 
value  of  conditional  expression  a. 

(4)  Procedural  transfer  of  control  (executing  a  sequence  of 
statements  and  then  returning  to  the  point  of  transfer) 
via  the  PERFORM  statement.  The  object  of  a  PERFORM  state¬ 
ment  is  either  a  paragraph  name,  or  a  pair  of  paragraph 
names  (denoting  the  lexical  sequence  of  paragraphs  between 
the  two  names).  All  statements  within  the  paragraph  or 
sequence  of  paragraphs  are  PERFORMed.  This  construct  can 
be  used  in  conjunction  with  a  condition  or  index  variable 
to  create  loops. 

Another  aspect  of  control  is  the  ALTER  statement,  which  makes  it  possible 
to  dynamically  change  the  object  of  a  GO  TO  statement.  In  programs  with 
ALTER  statements,  the  lexical  structure  becomes  far  removed  from  the 
dynamic  structure,  and  programs  with  this  property  are  verv  difficult  to 
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read.  Since  the  ALTER  statement  does  not  do  anything  that  cannot  be  accom¬ 
plished  by  flags  and  conditional  statements,  we  immediately  remove  it  from 
consideration  in  the  COBOL  subset  for  verification. 

All  four  types  of  control  statements  found  in  COBOL  are  also  found  in 
other  programming  languages,  and  present  essentially  no  inherent  problems. 

The  difficulties  occur  in  the  way  that  these  control  statements  interact. 

One  problem  is  that  loops  and  procedures  are  handled  by  the  same  syntactic 
mechanism,  the  PERFORM  statement.  The  mechanism  is  different  in  languages  such 

as  FORTRAN  and  PL/ I.  Thus,  the  same  paragraph  can  be  invoked  as  a  procedure 
or  as  a  loop  body.  Procedures  and  loops  are  handled  differently  for  veri¬ 
fication.  This  issue  is  discussed  in  Section  III.  Another  problem  is 
that  a  paragraph  that  appears  in  a  PERFORM  statement  can  also  be  invoked 
by  a  GO  TO  or  by  its  lexical  order,  further  complicating  verification. 

For  example,  the  paragraph  P  may  be  invoked  in  any  of  the  following 
situations : 

PERFORM  P.  (procedure  call) 

PERFORM  P  VARYING  I  FROM  1  TO  10. 

(loop  body) 

qq  T0  p  (unconditional  transfer) 

Q. 

MOVE  X  to  Y .  \  (lexical  order) 

P. 


Even  though  COBOL  contains  procedures,  (a  paragraph  or  sequence  of 
paragraphs  that  are  PERFORMed),  there  is  no  control  statement  that  permits 
a  direct  return.  Instead,  control  must  pass  to  the  last  statement  within 
the  scope  of  the  PERFORM.  COBOL  contains  a  nonexecutable  statement  that 
can  be  placed  at  the  end  of  the  scope  of  the  PERFORM  so  that  it  can  be 
the  destination  of  a  GO  TO.  This  is  the  EXIT  statement,  and  it  must 
occur  by  itself  in  a  paragraph.  It  resembles  the  CONTINUE  statement  of 
FORTRAN.  Although  the  execution  of  procedures  may  be  dynamically  nested, 
COBOL  provides  no  mechanism  for  a  corresponding  lexical  nesting  (such 
as  the  block  structure  of  PL/ I  or  Algol  60).  All  procedures  in  COBOL 
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occur  at  the  same  lexical  level  of  nesting.  For  example,  consider  the 
following  scheme: 

PI  . 

PERFORM  P2 . 

GO  TO  P3 . 

P2  . 

P3  . 

Paragraph  P2  is  at  an  inferior  dynamic  nesting  to  paragraphs  PI  and  P3 , 
but  has  the  same  lexical  nesting.  This  aspect  of  COBOL  makes  programs 
less  readable. 

To  handle  these  complexities  in  COBOL  control  constructs,  the 
verification  condition  generator  must  determine  the  manner  in  which  a 
paragraph  is  invoked  and  must  take  appropriate  action.  There  is  some 
trade-off  between  the  effort  involved  in  verification  condition  genera¬ 
tion  and  the  length  of  the  verification  conditions  that  are  produced.  We 
discuss  such  issues  in  Section  III. 

H .  Conclusions 

The  following  features  of  COBOL  present  major  problems  in  verification: 

(1)  Violation  of  the  abstraction  provided  by  COBOL 

(2)  Cons iderat ion  of  data  items  as  strings 

(3)  Implementor-defined  language  features. 

These  problems  are  dealt  with  by  excluding  the  offending  features  from  the 
CSV.  Strings  will  be  handled  in  future  work,  but  the  other  two  features 
must  be  continually  circumvented,  either  by  exclusions  from  the  subset  or 
by  showing  that  the  offending  features  do  not  affect  the  program’s  input/ 
output  behavior. 
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Some  other  features  that  cause  inelegancies  in  the  proof  process 
are  dealt  with  in  the  current  work: 

(1)  Semantically  unclean  control  statements 

(2)  Finite  machine  arithmetic. 

These  issues  are  symptomatic  of  programming  languages  in  general,  and 
we  intend — in  future  work — to  find  better  ways  to  approach  them. 
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Ill  THE  STRUCTURE  OF  THE  COBOL  VERIFICATION  SYSTEM 


A .  Introduction 

The  parts  of  the  verification  system  described  in  this  section  have 
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been  implemented  using  the  INTERLISP  language  on  a  PDP-10  running  the 

1 6 

TENEX  operating  system.  Although  LISP  is  inefficient  and  its  internal 

form  is  cumbersome  to  read,  it  is  the  easiest  and  most  powerful  of  languages 

for  writing  programs  that  process  structurally  complex  data.  In  future 

work,  we  intend  to  solve  the  problem  of  a  cumbersome  internal  form  using 

an  infix  printout  routine  to  print  out  LISP  expressions  in  the  more 

natural  infix  form,  without  parentheses.  However,  we  will  use  LISP,  with 

its  inefficiencies,  for  its  advantages  until  a  production  system  is  built. 

The  code  and  documentation  for  the  modules  of  ♦'he  system  we  have  built 

are  in  the  Appendix:  the  symbol  table,  the  posttransduction  processor, 

and  the  verification  condition  generator.  We  have  borrowed  the  facilities 
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for  transduction  grammars  from  other  work  at  SRI. 

4 

As  described  in  Section  I,  to  prove  a  program  by  using  Floyd's  method, 
one  must: 

(1)  Derive  a  set  of  mathematical  formulas  called  "verification 
conditions"  (VCs)  whose  validity  is  equivalent  to  the 
partial  correctness  of  the  program. 

(2)  Prove  the  validity  of  the  VCs,  either  by  hand  or  with  the 
aid  of  a  program  called  the  deductive  system. 

Our  approach  to  verification  entails  decomposing  the  process  of 
producing  verification  conditions  into  three  parts:  syntax  transduction, 
posttransduct  ion  processing,  and  low-level  verification  condition  genera¬ 
tion.  Briefly,  syntax  transduction  allows  for  the  processing  of  a  program 
in  a  syntactically  complex  (and  possibly  changing)  language  into  a  less 
syntactically  complex  internal  form.  Posttransduction  processing  trans¬ 
lates  the  first  internal  form  into  a  second  internal  form  of  reduced 
semantic  complex! ty . so  that  the  low-level  verification  condition  generator 
can  be  as  simple  as  possible.  We  have  built  all  of  these  modules  for 
COBOL  verification  condition  generation.  We  believe  that  this  approach 
to  structuring  the  verification  condition  generator  has  substantially 
reduced  the  effort  involved  in  writing  the  programs. 


j  r.L.  >LL'i  .  sj  t  r 
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The  deductive  system  would  be  decomposed  into  two  parts:  the  heuristic 
deductive  systems  and  the  proof  checker.  Since  the  validity  of  a  formula 
in  first-order  logic  is  undecidable  (verification  conditions  are  written 
in  first-order  logic),  we  need  one  or  more  heuristic  systems  that  can 
attempt  to  arrive  at  proofs,  based  on  strategies  depending  on  particular 
high-level  domains  of  inference  (e.g.,  COBOL  data  structures).  These  heuris¬ 
tic  deductive  systems  will  often  have  human  guidance.  To  assure  logical 
soundness,  the  outputs  of  these  heuristic  deductive  systems  (i.e.,  the 
proofs)  must  be  checked  against  a  strict  formal  system.  A  program  that 
checks  a  proof  for  logical  soundness  is  called  a  "proof  checker."  The 
separation  of  heuristic  deduction  and  proof  checking  results  from  the 
fact  that  we  want  the  heuristic  deductive  systems  to  operate  at  a  high 
level  of  abstraction--to  take  shortcuts  and  to  use  powerful  rules  of 
inference--but  the  proof  checker  must  operate  at  the  most  primitive  level 
of  logical  deduction.  The  separation  means  that  only  the  proof  checker 
need  be  correct,  to  guarantee  valid  deductions.  That  is,  an  incorrect 
proof  caused  by  a  bug  in  the  heuristic  deductive  system  will  be  revealed 

by  the  proof  checker.  We  have  built  no  machinery  of  this  type  specifically 
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for  COBOL  verification,  although  other  work  at  SRI  has  been  using  this 
approach  to  make  deductions  about  verification  conditions  for  JOVIAL 
programs.  We  expect  to  use  some  of  the  components  of  the  JOVIAL  verifi¬ 
cation  system  in  future  work  on  COBOL. 

The  structure  of  the  entire  verification  system  is  depicted  in 
Figure  1 1 1  —  I .  Other  parts  of  this  section  are  devoted  to  the  subsystems 
developed  in  this  project:  syntax  transduction,  posttransduction  processing, 
and  verification  condition  generation. 


B .  Syntax  A na ,lys i s  and  Tran sduction 

We  use  a  table-driven  language  processor  for  initial  processing  of 
COBOL  programs  that  are  to  be  verified.  Syntax  transduction  is  the 
process  of  translating  an  input  program  from  the  standard  form,  in  which 
COBOL  programs  are  written  by  users  of  the  language,  to  an  abstract  form 
with  the  same  semantic  properties  but  with  a  uniform  structure  easily 
manipulated  by  a  pos t t r ansduc t i on  processor  (the  next  phase  of  verifica¬ 
tion).  The  transduction  phase  is  especially  helpful  in  dealing  with 
COBOL,  which  has  extensive  syntactic  complexities  that  do  not  reflect  comparable 
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FIGURE  111-1  STRUCTURE  OF  THE  SRI  COBOL  VERIFICATION  SYSTEM 


semantic  complexities.  The  point  of  the  syntactic  complexity  of  a  language 
is  to  allow  programmers  to  write  in  an  expressive  and  natural  format.  While 
such  a  format  is  suitable  for  human  consumption,  it  is  inappropriate  for  the 
sorts  of  machine  manipulation  needed  in  verification.  It  is  consequently 
beneficial  to  translate  the  external  form  to  the  syntactically  much  simpler 
abstract  form  that  we  have  devised. 

The  correspondence  between  the  internal  and  external  forms  is  specified  by 
a  transduction  grammar.  Such  a  grammar  consists  of  a  set  of  BNF  produc¬ 
tions  to  describe  the  COBOL  language,  and  a  corresponding  transduction 
for  each  production.  A  transduction  is  a  LISP  program  that  computes 
the  abstract  form  of  the  language  fragment  specified  by  the  associated 
production.  Thus,  we  translate  a  COBOL  program  to  an  abstract  form 
(called  "Transduced  COBOL")  by  using  a  parser  to  analyze  a  valid  program 
into  a  "parse  tree"  according  to  the  productions  of  the  grammar,  and  then 
process  the  parse  tree  from  bottom  to  top  usirg  transductions  to  obtain 
the  parts  of  the  desired  Transduced  COBOL  program. 

Our  transduction  grammar  for  COBOL  (described  in  Section  IV),  together 
with  various  parsing  and  grammar  manipulating  tools,  not  only  specifies 
the  correspondence  between  COBOL  and  Transduced  COBOL,  but  also  consti¬ 
tutes  an  efficient  algorithm  for  translating  between  the  two  languages. 

As  a  result  of  this  translation,  while  a  user  may  submit  to  the  COBOL 
Verifier  a  general  COBOL  program  (suitably  annotated  by  logical  assertions), 
parts  of  the  system  operating  after  transduction  need  to  deal  only  with  a 
very  limited  set  of  semantic  primitives.  For  example,  in  the  PROCEDURE 
DIVISION  the  translation  expresses  all  ADD,  SUBTRACT,  MULTIPLY,  DIVIDE, 

COMPUTE,  and  MOVE  sentences  (except  for  the  CORRESPONDING  option,  which  is 
handled  separately)  in  terms  of  two  semantic  primitives  SET$  and  SETROUNDED$. 
The  DATA  DIVISION  of  a  COBOL  program  is  also  transduced,  but  to  a  slightly 
different  end.  Instead  of  having  a  program  as  output,  the  transductions 
for  the  DATA  DIVISION  construct  a  symbol  table  from  the  tree-structured 
data  declarations.  This  symbol  table  contains  a  data  item's  PICTURE 
specification,  together  with  its  ancestors  and  descendants  in  the  declara- 
■  ion  tree.  This  information  is  used  in  post  transduct  ion  processing  and  in 
verification  condition  generation  for  handling  roundoff  and  truncation, 
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for  disambiguating  qualified  references  to  data  items,  and  for  interpreting 
commands  like  MOVE  CORRESPONDING  (see  the  general  description  of  this 
verb  in  Section  II  and  a  specific  semantic  treatment  in  Section  VI). 

Finally,  observe  the  advantage  that  derives  from  employing  a  COBOL 
Transduction  Grammar  (CTG)  to  drive  the  transducer.  Although  we  have 
made  a  number  of  simplifying  assumptions  for  the  initial  phase  of  the 
project,  we  can  extend  the  subset  of  COBOL  that  is  accepted  simply  by 
augmenting  the  CTG.  Such  extensions  require  no  modification  of  the 
transducer. 

As  an  example  of  part  of  a  transduction  grammar,  consider  the 

following  example,  not  part  of  COBOL.  For  the  COBOL  transductions  see 

Section  IV.  In  this  example,  as  in  the  verification  system,  the  trans- 
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duced  form  of  the  program  is  an  S-expression  in  LISP.  The  BNF  rule 
has  two  alternatives  as  follows: 

ifthenelse  : :  =  IF  boolexp  statement  ELSE  statement.  I 
IF  boolexp  statement., 

where  the  upper-case  words  are  terminal  symbols  and  the  lower-case  words 

are  nonterminal  symbols.  The  transduction  may  look  like  this: 

ifthenelse  . :  =  <IF$  T2  T3  T5> ! 

< IF$  T2  T3  NIL- 

The  angle  brackets  denote  that  the  symbols  between  them  are  to  be 
assembled  into  a  list.  IF$  is  a  special  terminal  symbol  of  the  trans¬ 
duced  form  of  the  language.  Tn  (where  n  is  a  positive  integer)  denotes 
the  transduction  of  the  n**1  symbol  in  the  corresponding  BNF  rule.  Trans¬ 
duction  for  terminal  symbols  is  an  identity,  while  transduction  for  nontermi¬ 
nal  symbols  is  governed  by  other  transduction  rules.  Thus,  T2  refers  to 
the  transduction  of  "boolexp”  in  both  productions.  NIL  is  the  LISP  atom 
referring  to  the  null  list.  Thus,  if  we  have  the  statement 

IF  xl  THEN  x2  ELSE  x3  .  , 

its  transduction  is 

<IF$  T (xl )  T(x2)  T (x3) )  , 

where  T(xn)  is  the  transduction  of  xn  (xn  can  contain  complicated  arithmetic 
or  logical  expressions). 
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c. 


Posttransduction  Processing 


A  program  in  transduced  COBOL  looks  much  like  a  COBOL  program:  the 
statements  have  a  one-to-one  correspondence( and  the  control  statements 
(and  many  of  the  verbs)  are  the  same.  Posttransduction  processing 
reduces  the  semantic  complexity  by  operations  of  the  following  types: 

(1)  Translating  input  and  output  statements  into  array 
accesses . 

(2)  Translating  MOVE  CORRESPONDING  statements  into  MOVE 
with  elementary  data  items. 

(3)  Translating  PERFORM  constructs  into  equivalent  con¬ 
structs  containing  assignments,  tests,  and  branches. 

(4)  Adding  machinery  for  qualification  (unique  naming)  and 
truncation . 

The  result  is  an  equivalent  program  that  is  written  in  a  semantically 
much  simpler  language.  The  posttransduced  program  is  longer  than  the 
program  before  transduction,  however,  and  a  certain  trade-off  is  suggested 
the  verification  system  -.an  be  made  more  complex  so  as  to  handle  programs 
in  a  semantically  more  complex  language,  but  the  intermediate  forms 
(including  the  verification  conditions)  then  will  be  more  concise.  The 
specific  issues  (relative  to  COBOL)  in  this  trade-off  will  be  discussed 
in  Section  VI. 

The  functions  performed  by  posttransduction  processing  could  have 
been  performed  in  either  the  transduction  phase  or  the  verification 
condition  generation  phase.  We  wished  to  have  an  internal  form  (in 
Transduced  COBOL)  that  resembled  a  real  COBOL  program,  so  we  did  not 
make  the  drastic  program  changes  (involving  control  and  verb  changes) 
during  the  transduction  phase.  On  the  other  hand,  the  design  of  programs 
to  generate  verification  conditions  can  be  an  inordinately  difficult  task 
when  done  on  a  semantically  complex  language.  Thus,  we  did  not  include 
posttransduc tion  processing  in  the  verification  condition  generator. 

D .  Verification  Condition  Generation 

The  output  of  posttransduction  processing  is  a  program  that  contains 
only  the  following  kinds  of  statements: 
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(1)  Assignment  statements 

(2)  Array  accesses 

(3)  Branches  and  sequencing 

(4)  Tests  (IF  _  _  ELSE  _  statements). 

A  posttransduced  COBOL  program  can  be  thought  of  as  a  simple  flowchart 
scheme,  with  assertions  at  particular  points  in  the  flowchart  graph 
and  with  assignment  statements  and  array  accesses  in  the  flowchart  boxes. 

A  typical  flowchart  scheme,  with  numbered  assertions,  is  depicted  in 
Figure  I I 1-2 .  The  verification  condition  generator  must  identify  all 
simple  paths  in  the  program:  those  with  an  assertion  at  the  beginning, 
some  statements  in  the  middle,  and  an  assertion  at  the  end.  This  involves 
some  graph  analysis,  and  yields  results  as  shown  in  Figure  1II-3  when 
the  graph  of  Figure  III-2  is  processed. 

The  next  stage  is  to  transform  each  of  the  simple  paths  into  a 
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verification  condition.  We  use  Hoare's  axioms  to  show  how  the  four 
kinds  of  statements  are  handled.  In  Hoare's  axioms,  the  construction 
P{S}Q  means  that  if  P  holds  before  the  execution  of  statement  S,  then 
Q  holds  after  its  execution.  In  the  examples,  we  use  a  language  con¬ 
taining  only  assignments,  tests,  and  branches.  In  Section  VI,  we  show 
the  correspondence  between  COBOL  and  this  simple  language. 

In  the  case  of  assignment,  we  have  the  following: 

P{X-  e}Q  =  P  3  Q* 

This  means  that  the  correctness  of  an  assignment  statement,  with  respect 
to  assertions  P  and  Q,  is  equivalent  to  the  validity  of  the  formula  on 
the  right-hand  side,  in  which  expression  e  f.as  been  substituted  for  the 
variable  X.  For  example,  this  simple  assignment  to  X  yields  the  following 
VC  that  is  trivially  valid: 

X  <  0  {X  -*-X  +  1  }  X  <  1  = 

X<OoX+l<l 

In  the  case  of  array  accesses, we  describe  the  following  identities: 

A(I) f  SELECT (A ,  I) 

A  ( I )  <-  e  e  CHANGE  (A,  I,  e)  . 


The  first  identity  applies  only  when  A(I)  occurs  on  the  right-hand  side 
of  the  assignment  statement.  We  do  not  check  the  bounds  of  X  here.  The 
one  transformation  that  applies  is 

SELECT (A , x) 

PtCHANGE(A,I,e)]Q  =  POQ 

if  x  =  i  then  e  else  SELECT (A, x) 

Here  x  is  a  quantified  variable.  An  example  of  verification  conditions  in 
an  array  assignment  is  as  follows: 

<A[3]  =  2  A  a[4 ]  =  1 )  £a [ 3 ]  -e  5}  A[4]  =  1  = 

( A  [  3]  =-  2  A  a[4]  =  1)  3  (if  3  =  1  then  5  else  A[4])  =  1  . 

Branches  are  handled  by  the  path  analyzer,  but  a  single  flowchart  box  might 
still  have  a  sequence  of  statements  inside  it.  The  rule  that  defines 
verification  condition  for  sequencing  is  as  follows: 

P{  Sx ;  S2  >Q  =  P{  S1 }  Rj  A  R2{S21  Q  A  -3  R2  . 

In  actual  verification  condition  generation  this  rule  is  usually  applied 
by  "pushing”  the  consequent  assertion  (Q)  through  statement  S2  and  then 
through  .  This  means  that  two  different  substitutions  are  performed 
in  Q,  the  first  yielding  R^ (5  R2>,  and  the  second  yielding  some  predi¬ 
cate  R  ,  such  that  the  path  correctness  is  equivalent  to  P  ^  R  .  The 
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following  is  an  example  of  a  verification  condition  for  simple  sequencing: 

X  <  0  { X-*-  X  +  1;  X+X  +  2}  X  <  3  ■ 

(X<  0  {X+X+  1}  X<1)  A  (X<l{X-rX  +  2'tX<3)A(x<l=>X<l) 

The  effects  of  branching  are  largely  eliminated  by  a  transduction 
to  a  flowchart  scheme.  However,  this  can  be  dealt  with  via  the  following 
Hoare  axioms: 

P,  { GO  TO  L }  A _ A  P  {GO  TO  L }  A  Q{  L :  }  = 

1  n  - 

(  P^  ...  V  Pn)  -^Q  (Px  3  V  V  ‘  •  V  <Pn  3  9n)  ' 

Since  we  are  not  concerned  with  the  postconditions  of  the  statements,  they 
are  omitted.  In  this  axiom,  there  must  be  no  more  than  n  statements  in  the 
program  that  say  "GO  TO  L”.  In  COBOL,  we  require  that  assertions  be  placed 
at  all  labels  that  are  the  destinations  of  a  GO  TO,  so  that  the  assertions 
P^  do  not  have  to  be  written.  Instead  P^ H  . 
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The  effects  of  a  test  are  as  follows: 

P{test:  B(true) )Q=  P  A  B  O  Q 

P{  test :  B(false)  }  Q  s  P  A  -i  B  3  q  . 

Two  examples  of  verification  conditions  arising  from  a  conditional  state¬ 
ment  are : 

X  2  l{ IF  X  <  2  GO  TO  LI  ELSE  GO  TO  L2}  A 

X  =  1  { L 1 : _ }  = 

X  s  1  A  X  <  2  3  X  =  1 ,  and 
X  &  1  { IF  X  <•  2  GO  TO  LI  ELSE  GO  TO  L2}  A 

X  /-  1  { L2 : _ }  = 

X  1A  n(X  <  2)  3  X^l . 

The  verification  conditions  (logical  formulas)  for  the  program  must 
then  be  proved  valid  for  the  program  to  be  correct. 

E .  Conclusions 

The  method  we  used  resulted  in  a  simple  system  for  generating  COBOL 
verification  conditions,  so  that  most  of  the  processing  occurs  in  the  phases 
of  transduction  and  posttransduction  processing. 
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IV  SYNTAX  OF  THE  COBOL  SUBSET 


A .  Introduction 

We  have  used  the  general  guidelines  presented  in  Section  II  to 
choose  the  syntax  of  the  COBOL  subset  for  verification  (CSV).  For 
each  of  the  DATA  DIVISION  and  the  PROCEDURE  DIVISION,  we  present  a 
description  of  the  features  included  in  the  subset  and  a  discussion 
of  its  transduction  grammar.  Both  the  DATA  DIVISION  and  the  PROCEDURE 
DIVISION  have  features  from  the  Nucleus,  the  Table  Handling  Module  and 
the  Sequential  I/O  Module.  The  features  discussed  are  parts  of  Levels  1 
or  2  in  the  COBOL  language  description.  In  the  conclusion  to  this  section, 
we  discuss  possible  expansions  to  the  subset. 

B.  DATA  DIVISION  Features 

The  DATA  DIVISION  contains  the  declarations  for  records  and  variables 

* 

associated  with  files  and  with  the  program  in  general.  Table  IV-1  con¬ 
tains  a  list  of  the  features  of  the  DATA  DIVISION,  and  an  indication  about 
whether  or  not  they  are  allowed  in  the  CSV.  Table  IV-2  contains  a  syn¬ 
tactic  description  of  the  DATA  DIVISION  of  the  CSV,  in  the  same  style  as 
the  ANSI  COBOL  manual.  This  enables  a  straightforward  comparison  of  the 
CSV  syntax  with  the  syntax  of  COBOL  74  as  described  in  [11].  The  features 
of  the  Nucleus  deal  with  declarations  for  program  variables  and  records. 

The  facilities  used  for  declaring  such  variables  and  records  (e.g.,  PICTURE) 
are  also  used  in  the  declarations  of  variables  and  records  associated  with 
sequential  files.  We  enumerate  the  constructs  of  the  Nucleus  first.  We 
also  indicate  whether  or  not  a  feature  is  allowed  in  the  CSV.  If  a  feature 
is  disallowed,  we  explain  why. 

WORKING -STORAGE  SECTION  (allowed).  This  is  the  section  of  the  program 
that  allows  for  program  variables  and  records  that  are  not  associated  with 
a  particular  file. 

77-i terns  (or  Noncontiguous  Working  Storage)  (allowed).  These  are 
individual  variables  (not  records)  in  the  WORKING-STORAGE  SECTION. 


* 

The  Tables  are  at  the  end  of  the  section. 
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Data-names  or  FILLER  (allowed)  .  Data-names  can  be  either  elemen¬ 


tary  or  group  data  items  in  the  declaration  tree.  B'lLLER  denotes  an 
unnamed  data  item. 

JUSTIFIED  (disallowed).  For  an  alphabetic  or  alphanumeric  data 
item,  specifies  whether  right  justification  (filling  with  blanks  on  the 
left)  is  performed  when  a  smaller  data  item  is  MOVEd  to  it.  Left  justi¬ 
fication  is  the  default.  This  was  disallowed  because  we  have  not  allowed 
MOVTs  between  alphabetic  and  alphanumeric  data  items  of  different  sizes 
in  the  CSV. 

Level -numbers  (allowed) .  The  ordering  among  level  numbers  describes 
the  tree-structure  of  the  data  declarations. 

PICTURE  (partially  allowed) .  PICTURE  specifications  enable  a  des¬ 
cription  of  the  precision  and  printing  information  for  numeric  data  items, 
and  of  the  size  and  printing  information  for  nonnumeric  data  items.  The 
PICTURE  specifications  that  describe  special  printing  instructions  define 
edited  data  items,  which  we  do  not  allow.  The  rules  of  editing  and  the 
assertions  needed  to  describe  an  edited  data  item  satisfactorily  were 
deemed  to  be  too  complex  to  attempt  at  this  time.  The  assertions  that 
we  prove  in  this  initial  effort  deal  with  the  values  of  data  items  and 
not  with  their  printed  forms.  External  form  and  an  adequate  formal  treat¬ 
ment  of  string  data  is  a  subject  for  future  research. 

REDEFINES  (disallowed).  As  described  in  Section  II,  we  do  not  allow 
the  REDEFINES  concept  because  it  allows  the  same  area  of  storage  to  be 
described  in  two  different  ways,  sometimes  violating  the  abstraction  pro¬ 
vided  by  COBOL,  which  is  based  on  the  elementary  data  item.  We  acknowledge 
that  this  construct  is  a  very  powerful  programming  tool,  and  believe  that 
some  restrictior  of  REDEFINES  might  provide  much  of  the  power  without 
adversely  affecting  the  abstraction.  For  example,  a  possible  A  REDEFINES  B 
might  be  allowed  only  if  both 

(1)  B  is  an  elementary  data  item  of  form  9(n) ,  A(n) ,  or 
x (n)  . 

(2)  A  is  a  group  item,  all  of  whose  elementary  items  are  of 
the  same  type  as  B .  If  B  is  numeric,  then  no  elementary 
items  of  A  may  have  a  sign  symbol  S,  but  may  have  the  virtual 
decimal  point  symbol  V  or  precision  symbols  P.  If  B 
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is  numeric,  A  may  be  an  elementary  numeric  item  having 
a  virtual  decimal  point  V  or  precision  symbols  P. 

Thus,  a  possible  data  definition  could  be: 

02  B  PICTURE  9(9). 

02  A  REDEFINES  B. 

03  A1  PICTURE  999  PPP. 

03  A2  PICTURE  9999V99  . 

RENAMES  (disallowed).  RENAMES  allows  a  sequence  of  contiguously 
defined  elementary  data  items  (possibly  having  different  ancestors  in 
the  declaration  tree)  to  be  referred  to  by  a  single  group  data  item . 

This  allows  multiple  groupings  of  elementary  data  items.  It  has  minor 
benefits  in  the  MOVE  and  MOVE  CORRESPONDING  among  group  data  items.  We 
have  disallowed  the  simple  MOVE  among  group  data  items,  so  that  the  cur¬ 
rent  benefits  of  this  construct  seem  small  at  best.  Ultimately  we  should 
be  able  to  incorporate  the  construct  with  no  great  difficulty. 

SIGN  (disallowed) .  This  feature  allows  a  specification  of  the 
internal  representation  of  the  sign  of  a  data  item  as  being  leading  or 
trailing,  and  whether  the  sign  is  a  separate  character.  Since  we  are  not 
considering  the  internal  representation  of  a  data  item — only  its  value-- 
this  feature  is  of  no  use  in  the  current  subset.  Use  of  this  feature  does 
not  affect  the  correctness  of  a  COBOL  program. 

SYNCHRON I ZED  (disallowed).  This  feature  allows  the  programmer  to 
specify  that  a  data  item  is  aligned  (either  to  the  right  or  left)  on  a 
machine  word  boundary.  This  feature  affects  only  the  performance,  and 
not  the  correctness,  of  a  COBOL  program:  it  deals  only  with  a  represen¬ 
tation  issue. 

USAGE  (disallowed) .  This  feature  allows  the  programmer  to  specify 
whether  a  data  item  is  DISPLAY  (character-oriented)  or  COMP UT AT I ON A L - n 
(stored  in  some  format  useful  to  the  machine,  e.g.,  binary  integer  or 
floating-point  number).  This  again  is  a  representation  issue. 

VALUE  (disallowed).  The  initial  value  of  a  data  item  can  be  speci¬ 
fied  using  this  feature.  There  is  no  loss  of  generality  by  omitting 
this  feature:  a  programmer  can  initialize  a  data  item  via  an  assignment 
statement  at  the  beginning  of  the  program. 

The  Table  Handling  Module  has  only  a  single  feature  in  the  DATA 
DIVISION:  OCCURS  (partially  allowed).  This  feature  allows  the  declaration 
of  a  data  item  to  indicate  an  array.  The  array  cannot  be  of  variable  length. 


43 


However,  it  will  be  s traight forward  to  incorporate  the  use  of  variable- 
length  arrays  into  a  future  subset. 

The  features  oi  the  DATA  DIVISION  in  the  Sequential  1/0 
Module  permit  the  declaration  of  files  and  their  associated  records. 

The  FILE  SECTION  (allowed)  contains  zero  or  more  file  descriptions 
(allowed).  Each  file  description  contains  one  or  more  record  descrip¬ 
tions  (allowed),  the  components  of  which  ar<  described  below.  In  the 
CSV,  only  one  record  description  is  allowed  per  file  description. 

BLOCK  (disallowed).  This  optional  feature  declares  how  many  logical 
records  or  characters  are  associated  with  a  particular  block  (physical 
record).  The  verification  system  considers  logical  records  only.  Use 
of  this  feature  does  not  affect  the  input/output  behavior  of  the  program, 
only  its  efficiency. 

RECORD  (disallowed).  This  optional  feature  described  how  many 
characters  a  record  occupies.  This  clause  is  unnecessary  even  in  full 
COBOL  74  (it  is  placed  there  for  redundancy  only),  so  that  it  can  easily 
be  done  away  with. 

LABEL  (disallowed).  This  feature  (required  in  COBOL  74)  allows  the 
declaration  of  label  records  for  a  file  as  being  either  standard  (according 
to  the  operating  system)  or  omitted.  It  is  disallowed  for  the  same  reason 
as  the  BLOCK  clause.  VALUE  OF  (disallowed)  is  a  feature  that  either  checks 
or  sets  a  part  of  the  label  record. 

DATA  (disal lowed) .  This  optional  feature  specifies  the  data  records 
associated  with  a  file.  Since  the  data  records  oi  a  file  are  declared  in 
the  file  description,  this  feature  is  unnecessary. 

L INAGE  (disallowed).  This  optional  clause  provides  a  system  for 
keeping  track  of  pages  and  lines  within  a  page  in  a  sequential  file.  It 
is  useful  in  the  generation  of  reports,  and  is  omitted  from  the  CSV  because 
it  is  of  small  importance. 

CODE -SET  (disallowed).  This  optional  clause  specifies  the  character- 
code  (e.g.,  EBCDIC  or  ASCII)  used  in  the  external  representation  of  a  file 
and  is  disallowed  because  the  choice  of  character  code  does  not  affect  the 
input/ou Lpul  behavior  of  a  program. 
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C .  Transduction  Grammar  for  the  DATA  DIVISION 

The  transduction  grammar  for  the  DATA  DIVISION  yields 
an  internal  form  (part  of  Transduced  COBOL),  but  the  internal  form  is 
not  used  in  the  verification  of  a  COBOL  program.  However,  the  trans¬ 
duction  grammar  also  creates  a  symbol  table  containing  information  on 
each  data  item.  This  symbol  table  is  used  by  the  transductions  for  the 
PROCEDURE  DIVISION,  for  posttransduction  processing,  and  for  verification 
condition  generation. 

The  symbol  table  contains  information  on  files  and  on  data  items 
(both  group  and  elementary).  An  entry  for  a  file  name  contains  its 
type  (=  FILE)  and  its  corresponding  record.  An  entry  for  a  data  item 
contains  its  type  (=  DATA  ITEM)  and  either: 

(1)  If  the  item  is  a  group  data  item,  its  ancestors  in  the 
declaration  tree  (back  to  the  root),  its  immediate 
descendants,  and  the  number  of  elements  (if  an  OCCURS 
clause  exists) . 

(2)  If  the  item  is  an  elementary  item,  its  ancestors  in 
the  declaration  tree  (back  to  the  root)  and  its  PICTURE 
speci f ication . 

The  ancestors  (to  the  root)  are  used  in  qualification,  and  tne  descendants 
are  used  in  evaluating  the  MOVE  CORRESPONDING  verb. 

The  major  problem  in  constructing  the  symbol  table  is  to  take  a  flat 
description  of  the  declaration  tree  and  to  make  a  tree  structure  out  of 
it.  For  example,  a  COBOL  program  may  contain  a  data  declaration  like  this: 

01  A. 

02  B. 

03  C  PICTURE  99V99 . 

03  D  PICTURE  XXX 
02  E.  PICTURE  999. 

02  F. 

03  G  PICTURE  S999 . 

Although  there  may  be  indenting  within  the  tree-structure,  spaces  are 
ignored  in  parsing,  so  that  the  only  wav  to  determine  the  tree-structure  is 
by  means  of  the  level  numbers.  The  transduction  grammar  makes  each  item's 
declaration  into  a  list.  If  the  item  is  a  group  item,  then  the  group  item 
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will  be  the  first  element  of  a  list  with  the  descendants  forming 
another  list.  The  transduced  version  is  as  follows: 

(((1  A) 

(((2  B) 

((3  C  99V99) 

(3  D  XXX))) 

(2  E  999) 

((2  F) 

((3  G  S999 )))))) 

Here  is  a  graphic  representation  of  the  symbol  table: 


SYMBOL 

LEVEL  NUMBER 

ANCESTOR  PATTI 

DESCENDANTS 

PICTURE 

A 

1 

(B  E  F) 

B 

2 

(A) 

(C  D) 

C 

3 

(A  B) 

99V99 

D 

3 

(A  B) 

XXX 

E 

2 

(A) 

999 

F 

2 

(A  E) 

(G) 

G 

3 

(A  E  F) 

S999 

The  transduction  grammar  for  the  DATA  DIVISION  of  the  CSV  is  shown  in 
Table  rV-3. 

D.  PROCEDURE  DIVISION  Features 

The  PROCEDURE  DIVISION  contains  the  actual  code  and  assertions 
from  which  the  verification  conditions  are  generated.  Table  IV-4  con¬ 
tains  a  list  of  the  features  of  the  PROCEDURE  DIVISION,  and  an  indication 
about  whether  or  not  thev  are  allowed  in  the  CSV.  Table  IV-5  contains  a 
syntactic  description  of  the  PROCEDURE  DIVISION  of  the  CSV,  in  the  same 
style  as  the  ANSI  COBOL  manual.  We  enumerate  the  constructs  of  the 
PROCEDURE  DIVISION  tin  the  Nucleus,  Table  Handling,  and  Sequential  I/O 
Modules),  describing  the  features  and,  if  excluded  from  the  CSV,  the 
reasons  for  exclusion. 

ACCEPT,  DISP1AY  (disallowed).  The  ACCEPT  command  allows  for  input 
from  a  console,  or  of  the  day,  date,  or  time.  It  is  disallowed  because 
console  can  be  simulated  by  the  contents  of  a  sequential  file.  Even  if 
this  construct  were  allowed,  the  commands  issued  from  tiie  console  would 
have  to  be  described  as  part  o f  an  array  of  records,  whose  properties 
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are  described  by  assertions.  The  DISPLAY  command  is  disallowed  for 
the  same  reasons . 

ADD ,  SUBTRACT  (allowed).  All  versions  of  this  command  are  per¬ 
mitted,  including  ADD  and  SUBTRACT  CORRESPONDING.  All  arithmetic  state¬ 
ments  allow  rounding  (as  well  as  truncation,  the  default)  and  the  SIZE 
ERROR  clause. 

ALTER  (disallowed) .  This  command  can  dynamically  alter  the  flow¬ 
chart  of  a  program  by  changing  the  object  of  a  GO  TO  statement.  The 
set  of  possible  paths  through  the  program  becomes  too  large  to  handle 
for  verification.  The  effects  of  an  ALTER  statement  can  be  simulated  by 
the  use  of  flags  and  conditional  branches,  which  limit  the  number  of  pos¬ 
sible  program  paths  enough  to  permit  verification. 

COMPUTE  (allowed) .  This  is  a  generalized  assignment  to  an  arith¬ 
metic  expression.  The  ROUNDED  and  SIZE  ERROR  options  are  allowed. 

DIVIDE  (partially  allowed),  MULT IPLY  (allowed).  We  do  not  allow 
the  REMAINDER  option  of  the  DIVIDE  statement,  but  this  option  could  be 
included  in  a  future,  expanded  subset. 

ENTER  (disallowed).  This  verb  permits  the  inclusion  of  statements 
in  another  language  in  a  COBOL  program,  and  is  disallowed  for  obvious 
reasons . 

EXIT  (allowed).  This  is  a  no-op  statement  that  allows  exits  from 
PERFORM  blocks  (somewhat  like  the  FORTRAN  CONTINUE)  when  the  exit  state¬ 
ment  is  contained  in  a  paragraph  at  the  end  of  a  PERFORM  block.  This 
statement  must  be  the  only  statement  in  a  paragraph  in  which  it  appears. 

GO  (partially  allowed).  We  do  not  allow  the  DEPENDING  ON  option, 
which  could  be  included  without  adversely  affecting  verification.  We 
also  do  not  allow  an  option  (to  be  used  with  the  ALTER  statement)  in 
which  a  GO  TO  statement  may  have  no  arguments. 

IF  (allowed).  This  is  the  basic  conditional  statement. 

INSPECT,  STRING,  UNSTRING  (disallowed).  We  do  not  allow  any  string 
operators  in  this  subset.  We  hope  to  include  them  in  a  future  subset. 

MOVE  (partially  allowed).  We  allow  MOVE  between  elementary  data 
items  and  MOVE  CORRESPONDING,  but  we  do  not  allow  simple  MOVEs  between 
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group  data  items  (for  reasons  discussed  in  Section  II).  An  issue  that 
is  closely  related  to  the  MOVE  statement  is  that  of  type  coercion.  What 
happens  if  an  item  of  Type  A  is  moved  into  a  variable  of  Type  B?  In  some 
cases  there  is  a  simple  answer,  since  the  destination  type  subsumes  the 
source  type  (e.g.,  INTEGER  to  REAL,  ALPHABETIC  to  ALPHANUMERIC,  NUMERIC 
to  ALPHANUMERIC) .  In  other  cases,  a  policy  of  either  automatic  con¬ 
version  or  prohibition  must  be  decided  upon.  In  the  case  of  moving  a 
REAL  to  an  INTEGER,  this  is  solved  by  truncation.  The  remaining  problems 
are  ALPHANUMERIC  to  AIJ’HABETIC  and  ALPHANUMERIC  to  NUMERIC.  The  first 
case  is  not  important  because  there  are  no  operations  on  ALPHABETIC  data 
items  that  can  yield  errors  if  the  item  has  an  ALPHANUMERIC  value.  The 
second  case  is  not  so  simple:  COBOL  handles  it  by  allowing  a  MOVE  to  be 
performed  without  checking,  but  by  flagging  an  error  if  an  operation  is 
performed  on  the  destination  item.  This  is  disasterous  lor  verification, 
and  it  also  seems  harmful  to  good  programming  practice.  We  prefer  some 
scheme  that  allows  checking  to  be  done  when  a  MOVE  is  performed  (perhaps 
optionally).  We  also  favor  an  error  category  to  be  an  optional  part  of 
the  MOVE  statement:  "ON  TYPE  ERROR  statement."  There  are  many  advantages 
to  strongly  typed  languages,  one  of  which  is  increased  provability.  These 
proposals  are  intended  to  make  the  type  mechanism  in  COBOL  stronger. 

PERFORM  (allowed).  This  is  the  basic  textual  abstraction  and  looping 
mechanism  in  COBOL. 

STOP  (partially  allowed).  We  allow  this  statement  without  arguments 
only  (an  unconditional  stoppage  of  execution).  The  STOP  with  arguments 
prints  a  message  on  the  ..perator's  console  and  permits  restarting.  The 
latter  option  would  be  difficult  to  axiomatize. 

Some  ! eat ures  in  the  Nucleus  of  the  PROCEDURE  DIVISION  deal  with 
expressions  and  data.  We  enumerate  these  features  here.  Qualification 
(allowed)  enables  the  same  name  to  be  used  for  two  (or  more)  different 
paragraphs  or  data  items,  when  the  ambiguity  can  be  resolved  bv  referring 
to  a  section  name  or  to  an  ancestor  in  the  declaration  tree.  This  has 
added  considerably  to  the  complexity  of  the  symbol  table,  and  requires 
the  verification  system  to  make  the  names  unique  (at  si  ,e  time).  The 
verification  conditions  of  a  program  that  contains  ir  ,  e,  duplicated  names 
can  become  extremely  long.  Clearly  the  ability  to  name  two  things  with 
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the  same  name  is  desirable  (providing  for  such  features  as  MOVE  CORRES¬ 
PONDING,  for  example) .  It  remains  to  be  seen  what  restrictions  are 
necessary  to  allow  shorter  verification  conditions. 

Arbitrary  arithmetic  expressions  are  allowed  in  the  CSV.  However, 
we  do  not  allow  arbitrary  conditions.  Relation  conditions  (partially 
allowed)  deal  with  the  arithmetic  relations  >,  ■> ,  <  < and  We 
allow  arbitrary  relations  among  numeric  data  items,  but  allow  only  - 
and  ^  among  nonnumeric  data  items.  Class  conditions  (disallowed)  state 
whether  a  data  item  is  alphabetic  or  numeric,  and  can  easily  be  incor¬ 
porated  into  the  CSV  in  future  work.  However,  inclusion  of  this  feature 
is  closely  related  to  the  issue  of  type  coercion  (described  in  the  para¬ 
graph  on  the  MOVE  statement).  Condition -names  and  sign  conditions  (dis¬ 
allowed)  could  be  included  in  a  future  subset,  but  there  is  no  loss  of 
generality  from  excluding  them.  Swi tch-status  conditions  (disallowed) 
depend  on  an  implementor-defined  switch  and  should  not  be  allowed.  Com- 
plex  and  combined  conditions  (allowed)  arc  nothing  more  than  the  combining  of 
simple  conditions  (those  described  above)  with  AND,  OR,  and  NOT.  Abbrev- 
iated  combined  conditions  (disallowed)  are  a  shorthand  way  of  writing 
complex  and  combined  conditions  (e.g.,  "  X  >  Y  AND  X  >  Z"  translates  to 
"X  >  Y  AND  z") ;  they  are  needlessly  difficult  to  process  and  also  unneces¬ 
sary  . 

In  the  PROCEDURE  DIVISION  of  the  Table  Handling  Module,  there  are  two 
verbs  SEARCH  and  SET  (both  disallowed),  which  deal  with  indexing  variables 
(also  disallowed) .  The  only  operation  allowed  on  tables  (or  arrays)  is 
the  subscripting  operation,  in  which  a  table  is  indexed  by  an  expression, 
rather  than  a  special  indexing  variable. 

In  the  PROCEDURE  DIVISION  of  the  Sequential  I/O  Module  there  are  primi¬ 
tives  to  manipulate  sequential  files. 

CLOSE ,  OPEN  (partially  allowed).  These  statements  are  allowed,  but 
without  the  REEL  or  UNIT  designations  that  describe  a  file's  implemen¬ 
tation.  The  OPEN  statement  is  not  allowed  with  the  1-0  or  EXTEND  options, 
or  with  the  REVERSED  or  NO  REWIND  designations.  A  file  open  for  both 
INPUT  and  OUTPUT  can  be  simulated  (although  not  efficiently)  by  having  two 
files — one  for  INPUT  and  one  for  OUTPUT. 
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READ ,  WRITE  (partially  allowed).  The  INTO  option  in  READ  and  the 
FROM  option  in  WRITE  are  disallowed  (they  involve  a  MOVE  and  then  the 
READ  or  WRITE  operations) .  The  AT  END  clause  in  READ  is  permitted. 

All  clauses  in  the  WRITE  statement  dealing  with  pagination  are  disallowed. 

REWRITE  (disallowed) .  This  operation  deals  with  files  that  are  open 
for  both  INPUT  and  OUTPUT ,  which  is  not  allowed. 

USE  (disallowed).  This  statement  allows  the  specification  of  pro¬ 
cedures  for  input/output  errors.  The  only  error  that  ve  consider  is 
end-of-file,  which  is  handled  with  the  AT  END  clause  of  READ. 

E .  Transduction  Grammar  for  the  PROCEDURE  DIVISION 

The  transduced  version  of  the  PROCEDURE  DIVISION  is  used  in  the 
generation  of  verification  conditions.  The  transductions  are  usually 
a  one-to-one  translation  of  COBOL  verbs  except  that 

(1)  Each  verb  has  only  one  transduced  syntax,  subsuming 
all  alternatives. 

(2)  All  arithmetic  assignment  statements  are  reduced  to  the 
same  internal  form. 

(3)  Statements  implying  multiple  operations  are  translated 
into  multiple  statements. 

Other  transformations  to  the  internal  form  of  the  program  are  performed 
during  posttransduction  processing  and  verification  condition  generation. 

Each  COBOL  sentence  becomes  a  list.  Each  paragraph  is  a  list  whose 
first  element  is  the  keyword  PARAGRAPHS,  whose  second  element  is  the  para¬ 
graph  name,  and  whose  other  elements  are  its  transduced  sentences  in  order. 
Each  section  is  a  list  whose  first  element  is  the  keyword  SECTIONS,  woose 
second  demon'  is  lie'  section  name  (if  there  are  no  sections  a  section 
name — FIRSTSECTION--is  invented  for  the  section  consisting  of  all  para¬ 
graphs),  and  whose  other  elements  are  the  transduced  paragraphs  In  order. 

To  show  the  structure  of  the  entire  PROCEDURE  DIVISION,  we  present  the 
following  simple  COBOL  program: 

PI  (ASSERT  1 > 

MOVE  n  TO  SUM. 

PERFORM  P2  VARYING  I  FROM  1  BY  1 
UNTIL  I  GREATER  THAN  N 
v ASSERT  2). 

STOP  RUN  (ASSERT  3). 

P2 .  ADD  A  ( I )  TO  SUM 
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(PROCEDUREDIVISION? 

(SECTION?  FIRSTSECTION 
(PARAGRAPH?  PI 

(ASSERT  1) 

(SET?  SUM  0  NIL) 

(PERFORM  VARYING 

(DO?  PI  PI) 

(Ill  (GT  1  N)) 

(ASSERT  2)) 

(STOP  (ASSERT  3))) 

(PARAGRAPH?  P2 

(SET?  SUM 

(PLUS  SUM 

(SELECT  A  (I))) 

NIL)))) 

To  illustrate  some  interesting  features  of  the  transductions  at 
the  sentence  level,  we  present  some  examples  of  COBOL  verbs  and  their 
transductions.  As  an  example  of  a  simple  one-sentence  transduction, 
the  sentence 

CLOSE  FILE1 . 

transduces  to 

(CLOSE  FILE  1) . 

The  sentence 

IF  X  GREATER  THAN  0  NEXT  SENTENCE  ELSE  GO  TO  PI. 

transduces  to 

(IF  (GT  X  0) 

NEXT 
(GO  PI)) 

where  NEXT  can  tie  interpreted  by  the  verification  condition  generator. 
The  PERFORM  statement  is  an  interesting  case.  The  simple  PERFORM, 

PERFORM  PI . , 

transduces  to 

(PERFORM  (ONCE?) 

(DO?  PI  PI) 

NIL  NIL)  . 

ONCE?  is  the  option  used  to  denote  a  single  instance :  the  other  alter¬ 
natives  are  "n  TIMES"  and  VARYING.  DO?  indicates  that  the  block  of 
statements  from  PI  through  PI  are  the  scope  of  the  PERFORM  (this  can  be 
expanded  later).  The  two  instances  of  NIL  are  places  for  the  exit  con¬ 
dition  and  the  inductive  assertion,  when  the  statement  is  used  as  a  loop. 
The  PERFORM  statement  with  a  block  of  paragraphs, 
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PERFORM  PI  THRU  PN 


•  t 


transduces  to 

(PERFORM  (ONCE$) 

(00$  PI  PN) 

NIL  NIL) . 

A  simple  COBOL  loop  looks  like  this: 
PERFORM  PI 

VARYING  I  FROM  1  BY  1 
UNTIL  I  GREATER  THAN  N 
(ASSERT  (P  I)). 


(the  assertion  is  some  predicate  P  on  I)  ,  and  its  transduction  looks  like 
this  : 


(PERFORM  VARYING  (D0$  PI  PI) 

(I  1  1  (GT  I  N)) 

(ASSERT  (P  I))). 

A  nested  PERFORM  ot'  the  following  form, 

PERFORM  PI  VARYING  I  FROM  1  BY  1 

UNTIL  I  '  N  (ASSERT  (P  I)) 
AFTER  J  FROM  1  BY  1 

UNTIL  J  >  M  (ASSERT  (Q  I  J))., 


transduces  to 

(PERFORM  VARYING  (PERFORM  VARYING  (DOS  PI  PI) 

(J  1  1  (GT  J  M)) 

(ASSERT  (Q  I  J))) 

(I  1  1  (GT  I  N)) 

(ASSERT  (P  I))). 

All  simple  arithmetic  statements  (not  CORRESPONDING)  transduce  to  SET$ 
(if  truncated)  and  SETROUNDED$  (if  ROUNDED).  The  COBOL  sentence 

COMPUTE  X  ...  Y  *  /.. 

transduces  to 

(SETS  X  (PLUS  Y  /.) 

NIL)  . 


The  NIL  is  where  the  SIZE  ERROR  clause  would  go  if  present.  Notice  that 
arithmetic  and  relational  operators  are  translated  to  a  single  standard 
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form  for  use  in  the  verification  system:  PLUS,  SUBTRACT,  TIMES,  DIVIDE, 
GT(>)  ,  LT(<)  ,  GTQ(>) ,  LTQ(<) ,  EQ,  and  NEQ .  The  arithmetic  statements 
that  have  multiple  results  are  transduced  into  multiple  statements.  For 
example,  the  statement, 

COMPUTE  XI  ROUNDED,  X2  =  Y  +  Z;  ON  SIZE  ERROR  PERFORM  PI., 

transduces  to  the  pair  of  simple  statements, 

( SETROUN DE D$  XI  (PLUS  Y  Z)  ' 

(PERFORM  (ONCE$) 

(DO$  PI  PI) 

NIL  NIL)) 

(SET$  X2  (PLUS  Y  Z) 

(PERFORM  (ONCE$) 

(DO$  PI  PI) 

NIL  NIL)) . 

All  CORRESPONDING  operations  are  separate,  since  they  will  be  handled  in 
posttransduction  processing.  The  following  sentence, 

ADD  CORRESPONDING  X  TO  Y. , 

transduces  to 

(ADDCORRESPONDING$  X  Y  NIL  NIL). 

F.  Conclusions 

The  subset  of  COBOL  that  we  have  chosen  for  verification  is  small 

12 

relative  to  the  entire  ANSI  COBOL  language,  yet  it  is  a  substantial 
programming  language  in  itself — as  complex  as  any  for  which  verification 
has  been  attempted. 

There  are  two  important  things  in  the  Nucleus  that  are  yet  to  be 
axiomatized : 

•  The  handling  of  NUMERIC  EDITED  data  items,  with  possible 
restrictions 

•  Character  strings  and  their  relation  to  numeric  quantities. 

Two  unresolved  issues  affecting  the  ultimate  choice  of  a  subset  are  type 
coercion  and  a  restriction  of  the  REDEFINES  construct. 

In  the  Table  Handling  Module,  the  only  major  items  left  out  of  the 
CSV  are  indexing  variables  and  the  verbs  that  use  them.  It  appears  that 
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they  are  easy  to  axiomatize,  but  we  are  unsure  of  their  importance  to 
COBOL  programmers.  AH  operations  with  indexing  variables  can  be 
defined  in  terms  of  subscripting,  so  there  is  no  loss  of  generality  if 
we  fail  to  incorporate  them. 

The  major  unresolved  issue  in  the  Sequential  I/O  Module  deals  with 
files  that  are  open  for  simultaneous  input  and  output.  We  intend  to 
incorporate  this  into  future  COBOL  subsets  for  verification. 

It  is  not  only  important  to  axiomatize  a  large  subset  of  a  "real" 
language,  but  it  is  also  important  to  be  able  to  state  and  prove  the 
important  properties  of  the  subset  chosen.  Thus,  the  choice  of  subset 
must  be  judged  in  terms  of  what  can  be  proven,  as  well  as  its  sheer  size. 


Tab?  „>  IV-1 


SYNTAX  OF  THE  DATA  DIVISION  OF  THE  CSV 


GENERAL  FORMAT  FOR  DATA  DIVISION 


DATA  DIVISION. 

[FILE  SECTION . 

[~FD  file-name  f  record-description-entry] 

[WORKING-STORAGE  SECTION. 

77-le vel-desc r ip t ion-entry 
record -descript ion-entry 


GENERAL  FORMAT  FOR  DATA  DESCRIPTION  ENTRY 


level-number 


f data-name- 
1  FILLER 


L- 


picture’ 

PIC 


IS  character-string 
OCCURS  integer-!  TIMEsl 
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Table  IV-2 


FEATURES  FOR  THE  DATA  DIVISION  OF  THE  CSV 


— —  —  ■  -  ■■  ■  — — . — - — - 

D4TA  DIVISION  Feature 

COBOL  74 

COBOL  Subset  for 

Verification 

Level  1 

Level  2 

Level  1 

Level  2 

Nucleus 

* 

t 

WORKING-STORAGE  SECTION 

X 

X 

77 -i terns 

* 

X 

Data  name  or  FILLER 

X 

X 

•JUSTIFIED 

X 

uovel  numb e r 

X 

X 

* 

PICTURE 

X 

REDEFINES 

X 

REN  A.WES 

x 

sr® 

X 

SYNCHRONIZED 

X 

USAGE 

X 

VAT.UE 

X 

Table  Handling 

OCCURS 

X 

X 

X 

Sequential  I /0 

FILE  SECTION/file  descriptions 

X 

X 

BLOCK  contains 

X 

* 

RECORD  contains 

X 

LABEL  records 

X 

VULUE  OF 

X 

X 

DATA  RECORDS 

X 

LINAGE 

X 

CODE-SET 

X 

*  i  eat  11  re  included. 

4  (blank) — Feature  nonexistent  (in  COBOL  74)  or  omitted  (from  COBOL  subset 
fo  i  ■  »*r  i  f  i  cn  t  i  on  ). 

*  Feature  not  totally  included  (in  subset) 
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Table  IV-3 


IRANSDUCriON  GtRAi'-li  1A.R  FOR  frtfi 
DATA  DIVISION  OF  TrlE  CSV 


•root* 

v  datadivision 

( ri ) 


comma 

it 

(OIL) 

It  , 

{ ri ) 


datadescription 

It  number  dataname  pictureclause  occursclause  . 
( <T1  12  1 3  T4>) 


datadescriptions 
tt  datadescription 
( <  T 1  > ) 

It  datadescription  datadescriptions 
(<T1  !  T2> ) 


datadi vision 

It  DATA  DIVISION  .  tilesection  workingstoragesection 
(<  DATADIVISION*  T4  T5>) 


dataname 
It  FILLER 
(  '  FILLER* ) 
it  symbol 
( ri ) 


filedescriptor 

it  FD  symbol  .  datadescriptions 
( <T1  ( INSLR  i FILE  T2  i'4 : 1 : 1  : :  1 ) 

(PiWuN  (IN3i.Junc.C0RD  14:1:1:2  <T2>) 
(GETruXORu*  T4 ) ) 

>) 


filed  esc riptors 
If  filedescriptor 
(  <  T 1  >  ) 

if  filedescriptor  filedescriptors 
( < T 1  !  T2>) 


filesection 

if 

(NIL) 

if  FILE  SECTION  .  filedescriptors 
(< 'FILESECTION$  !  T4>) 


is 

if 

(NIL) 
If  ARE 
( T1 ) 

If  IS 
(T1) 


literal 
if  number 
(T1) 

If  string 
( T1 ) 


occursclause 

if 

(NIL) 

If  OCCURS  number  TIMES 
( T2 ) 


picture 
If  PIC 
(T1) 

If  PICTURE 
(T1) 


BEST  AVAILABLE  COPY 


pictureclause 

» 

(MIl) 

It  semi  picture  is  symbol 
(T4) 

It  semi  picture  is  number 

(.  r4) 


recordiist 
It  symbol 
(<T1>) 

It  symbol  comma  recordiist 
( <T1  !  T3>) 


semi 

It 

(MIL) 

#  ; 

( n ) 


wor ki ngs to rages ect ion 
it 

(MIL) 

it  w OrtKIiru-SiORAJE  SECTION  .  datadeclarations 
(<  ' wOHKIi'IGSr JKAuESECTION$  !  T4>) 
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Table  IV- 4 


SYNTAX  OF  THE  PROCEDURE  DIVISION  OF  THE  CSV 
GENERAL  FORMAT  FOR  PROCEDURE  DIVISION 


FORMAT  1 : 


PROCEDURE  DIVISION 

'  ■  —  —  -  — —  — • 

^section-name  SECT  ION . 

[ paragraph-name, 1  sentence] . . . 


FORMAT  2: 


PROCEDURE  DIVISION 


Jparagr 


aph-name.  [son 


tencc]  . . „  ^  ... 


GENERAL  FORMAT  FOR  VERBS 


ACCEPT’  identifier 


(identi  f  ior-1 "] 

,  identifier-2 

Jliteral-1  J 

,  literal-2 

t,  identif ier-n  [ROUNDED]  ., 


TO  identif ier-m  IROUNDKD1 

[;  ON  SIZE  ERROR  imperative-statement] 


f identif ier-ll  ("identif  ier-2l  identif  ier-3"| 

1  literal-1  J  ’  iliteral-2  )  I,  liceral-3  J 

CAVING  identifier-in  [ROUNDED]  [,  identifier-n  [ROUNDED]  ]... 
| ;  ON  SIZE  ERROR  imperative-statement] 


ADD  < 


fV'ORRES  ION  I)  IN  G 


CORR 


identifier-1  TO  identifier-2  [ROUNDED] 


[  ;  ON  S 1 ZE  ERROR  imperative-statement] 
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C 


CLOSE  file-name-1  |,  file-name-2 


:]  ... 


COMPUTE 


identifier-1  f ROUNDED 1  identifier-2  [ 


ROUNDED 


]]  ... 


=  arithmetic-expression  [;  ON  SIZE  ERROR  imperative-statement  ] 


DISPLAY 


fident if ier-1  | 

jliteral-1  J 


identifier-2 

literal-2 


]... 


DIVIDE  jiiteral-l1"1}  INT0  identifier-2  [ROUNDED] 

identifier-3  [  ROUN  PEP  ]j  ...  [ ;  ON  SI  ZE  ERROR  imperative-statement] 

DIVIDE  (ld®ntlf ler_1\  INTO  fidentlf 1®r_2l  GIVING  identifer-3  [  ROUN DED ] 
-  ]literal-l  J  -  [literal-2  J  -  - 

[,  identifier-4  [ROUNDED j  ...  [ ;  ON  SIZE  ERROR  imperative-statement] 

DIVIDE  |ld®ntl^1®r_1\  BY  {.ldfltlJ1!r_2  1  GIVING  identifier-3  [ROUNDED] 
-  |li teral-1  J  —  [literal-2  J -  - 


DIVIDE 


GIVING  identifier-3  [ROUNDED] 


identifier-4  [ROUNDED j  ...  [;  ON  SIZE  ERROR  imperative-statement] 


GO  TO  [procedure-name-1] 


statemeni 


NEXT  SENTENCE  f  \;  ELSE  NEXT  SENTENCE 


ier-2  [,  identifier-3]  ... 


,  (  statement-1  ); 

—  j  NEXT  SENTENCE 

(identifier-1 ]  __  .  ,  .... 

MOVE  <. . .  ,  TO  identifie 

-  llitcral  J  — 

_ _  [corresponding! . . 

—  jcoST - J  identifier-1 

MULTIPLY  (ld®nllf 1®1"1  \  BY  identi 
-  Iliteral-l  J  — 


ELSE  statement-2 


CORRESPONDIN'  < 


identifier-1  TO  identifier-2 


MULT  I  PI. 


BY  identifier-2  [ROUNDED] 


idcntifier-3  [  ROUNDED  j  ...  [" ;  ON  SIZE  ERROR  imperat  i  ve-s  tatemen  tj 


MULTI  PLY 


I  PLY  |.ld0ntlf1®r'1]  BY  ^ntlfior-2^  G  identifier_3  ,  ROUN  DED 1 

-  [literal-1  J  —  jliteral-2  J  -  1 - 

idcntifier-4  [ROUN DED ]j  ...  ON  SIZE  ERROR  imperat  ive-statementj 
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(identifier-1  'l 
SUBTRACT  1, _ 

-  (literal-1  J 

,  f,  identifier-2 

1  ,  literal-2 

...  FROM  identifier-m  ^ROUNDEDj 

identifier-n  [ROUNDED]J  ...  [  ;  ON 

SIZE  ERROR  imperative-statement] 

(identifier-1 L 
SUBTRACT  f 

identifier-2 
|  ,  li teral-2 

1  _ (identifier-m  ) 

I  t>f  kiteral-m  1 

(literal  I  J 

I  11  X  LcX  dl  1(1  ( 

GIVING  identifier-n 

[ROUNDED]  [,  identifier-o  [ROUNDED] J  ... 

[;  ON  SIZE  ERROR  Imperative-statement] 


SUBTRACT 


CORRESPONDING 

CORR 


} 


identifier-1  FROM  identifier-2  [ROUNDED] 


[;  ON  SIZE  ERROR  imperative-statement] 


WRITE  record-name 


GEN ERAL  FORMAT  FOR  CONDITIONS 


RELATION  CONDITION: 


f identifier-1 
J  li teral-1 

\  arithmetic-expression-1 
\_index-name~l 


IS  [NOT]  GREATER  THAn\ 


IS  [NOT]  LESS  THAN 
IS  [NOT]  EQUAL  TO 
IS  [NOT]  > 

IS  [NOT]  < 

IS  [NOT]  = 


l  fidentif ier-2 
/literal-2 

|  arithmetic-expression-2 
V.index-name-2 


CLASS  CONDITION  : 

identifier  IS  [NOT] 

NEGATED  SIMPLE  CONDITION: 

NOT  simple-condition 
COMBINED  CONDITICN  : 


NUMERIC 

ALPHABETIC 


/  (and']  I 

cond  1  tion  \  j  condition  f  ... 
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MISCELLANEOUS  FORMATS 


QUALIFICATION 


(data-name-1  ! 
Jcondi t ion-name  j 


paragraph-name 


is) 

ill 


data-name-2 


section-name 


SUBSCRIPTING: 


[data  name  1  (subscript-l  [,  subscript-2  [,  subscript-3]-)  ) 

J_cond  1  tion-name  J 


IDENTIFIER : 


da  ta-najne-1 


jj§  j  da  ta-name-^J  ...  [( 


(subscript-1  (,  subscript-2 


,  subscript-3]  )j 
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Table  IV-6 


TRANSDUCTION  ORAi-k-iAR  FOR  THE 
PROCEDURE  DIVISION  OF  THE  CSV 

proeeduredi vision 

#  PROCEDURE  DIVISION  .  paragraphs 

(<  PROCEDUR£DIVISION$  <' SECTION*  ' FIR3TSECTI0N  I  T4>>) 

#  PROCEDURE  DIVISION  .  sections 
(< 'PROCEDUREDI VISION*  !  T4>) 


at 

# 

(NIL) 
#  AT 
(NIL) 


computetarget 
(I  computetarget  1 
( <  T I  >  ) 

#  identifier  ,  computetarget 
(<<  S£T$  T1>  (  T3>) 

1/  identifier  ROUNDED  ,  computetarget 
( <<  SET ROUNDED*  T1>  !  T4>) 


computetarget 1 
v  identifier 
(<'SET$  T1>) 

»  identifier  ROUNDED 
( < ' SETROUNDLD*  T1>) 


condition 

It  condition  OR  condition2 
( <T2  T1  1'3>) 

It  condition2 
(T1) 


condition2 

It  condition2  AND  condition3 
(<T2  T1  I‘3> ) 
if  condition3 
(  T 1 ) 


66 


conditions 

It  NOT  conditions 
( <T1  i 2>) 

K  condition4 
(T1) 


condition^ 

#  (  condition  ) 

( T2 ) 

It  siraplecondition 

(  ri ) 


connector 
It  BY 
(il) 

It  FROM 
( T 1 ) 

#  Ii^ij 

cri) 

It  TO 
( T1 ) 


corresponding 
It  CORR 
(NIL) 

It  COR  R  to  BON  LINO 
(NIL) 


corrop 
It  ADD 

( ’ ADDC0RRL3P0NDINU$) 

It  SUBTRACT 

( 'SUBTRACTCORRESPGNDINU$) 


dividearguments 
It  expression  BY  expression 
(<T1  T3>) 

It  expression  INTO  expression 
(<T3  T1>) 


elseclause 

# 

( 'NEXT) 

#  semi  ELSE  NEXT  SENTENCE 
( 'NEXT) 

#  semi  ELSE  sentence 
(13) 


endcondition 

It 

(NIL) 

#  ;  at  END  sentence 
(T4) 

#  at  END  sentence 
( T3) 


errorcondition 

u 

(NIL) 

tt  ;  on  SIZE  ERrtoR  sentence 
(IS) 


expression 

4  expression  +  expressions 
(<  PLUS  T1  I3>) 

It  expressions 
( ri ) 

It  expression  -  expression2 
(<  SUBTRACT  T1  T3>) 


expressions 

#  expressions  *  expression3 
(<  TIMES  II  T3>) 
it  expression2  /  fcXpression3 
(<  DIVIDE  II  T2->> 

It  expression3 

'  rn 


expression3 

It  expression 3  **  expression^ 
(  <  EXF  ri  i'3> ) 
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If  expression4 
(T1) 


expression 

If  (  expression  ) 

( 12 ) 

If  +  expression4 

( T2 ) 

it  -  expression4 
(<  'lilRuS  T2>) 

if  ZERO 
(0) 

#  ZEROES 
(0) 

if  ZEROS 
(0) 

if  identifier 
(T1) 

If  number 

( T1 ) 

if  string 

( T 1 ) 


expressions 
if  expression 
«T1>) 

If  expression  ,  expressions 
( < T 1  !  Ti>) 


filename 
If  symbol 
crn 


filenames 
If  filename 
(<T1>) 

it  filename  ,  filenames 
(<T1  !  T 3 > ) 
if  filename  filenames 
( <T 1  !  T2>) 


ident 1 t ier 

#  symbol  suoscri ptlist  qualifiers 
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((if  12  tnen  <  SELECT 

(if  1’3  tnen  <'QUAL  T1  !  T3>  else  T1) 

i'2>  elseir  T3  tnen  < '  (JUAL  T1  I  T3>  else  T1 ) ) 


identifiers 
it  identifier 
( <  T 1  > ) 

#  identifier  ,  identifiers 
(<T1  !  T3>) 


indexname 
it  symbol 

( n ) 


iotype 
it  INPUT 

(  OPEN! JPUT$ ) 
it  OUTPUT 

( ' GPENGUTPUT$ ) 


IN 

(M  lu't 
OF 

(MIL) 


(NIL) 

OM 

(NIL) 


operator 
It  ADD 
( 'PLUS) 

It  Di VIDE 
( 'DIVIDE) 

#  MULTIPLY 
( 'TIrtES) 

#  SUBTRACT 

( 'SUBTRACT) 


paragraph 

It  paragrapnname  .  sentences 
(< 'PARAGRAPH!  T1  !  T3>) 


paragrapnname 
#  symbol 

( n ) 


paragrapns 
It  paragraph 
(<T1>) 

It  paragraph  paragrapns 
( <T1  J  T2» 


performbody 
it  procedurename 
(<  D0$  T 1  TO) 

if  procedurename  tnru  procedurename 
( < ' D0$  T1  1 3>  ) 


performcontrol 

It  UNTIL  condition  assertion 
( <T2  ri  T3>) 

it  expression  TIMES  assertion 
( <T2  II  I3>) 

it  varying  identil'ier  FROM  expression  BY  expression  UNTIL  condition 
assertion 

(<T1  <12  14  1 6  T8>  T9>) 


per  f  ormcon  trois 
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(NIL) 

#  perforracontrol  perforracontrols 

(<T1  !  T2>) 


procedurename 
It  symbol 
( T1 ) 

ft  symbol  of  symbol 
( <T  1  1'3>) 


procedurenames 
If  procedurenarae 
( <T 1 > ) 

It  procedurename  ,  procedurenames 

(<T1  !  T3>) 


qual if iers 
It 

(  N I L  ) 

it  of  symbol  qualifiers 
(<T2  !  T3>) 


rec  ordname 
it  symbol 

(in 


re  .at  ionoperator 
it  Noi  relat ionoperator 2 
vvoiLidw  12  (l  QUO  it.  EQ) 

*  NEQ) 

( ( QUOTE  N£Q) 

'EQ) 

(  1  QUO i &  LT  ) 

'OTQ) 

( ( QJOiu  GTQ) 

'Ll) 

((QUOTE  LlO) 

GT ) 

( (,  QUO  ir,  UD 
'  LTQ) 

(  HbLP 

’Error  in  reduction  of  first  alternative  of  relat ionoperator .")) ) 

ii  !-p la  -  ; os .  'perator2 
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( T1 ) 


relationoperator2 
#  < 

(#LT) 

#  = 

CEQ) 

#  > 

(  'GT) 

#  EQUAL  to 
(  '  EQ) 

#  GREATER  tnan 
(  GT) 

t  LESS  tnan 

Clt) 


rounded 

(NIL) 

#  ROUNDED 
( T1 ) 


section 

#  sectionname  SECTION  .  paragraphs 
{ < ’ SECTIONS  ri  I  T4>) 


sectionname 
#  symbol 
( T 1 ) 


sections 

#  section 
( <T1 > ) 

#  section  sections 
( <T1  !  T2>) 


semi 

# 

(NIL) 

*  ; 

(NIL) 
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sentence 
It  sentencel 

( T1  ) 

It  sentence2 

((if  T 1 : : 1  tnen  <'D0$  !  T1>  else  T1 s 1 ) ) 


sentence  1 

It  CLOSt  filenames 
(<T1  !  f2>) 
it  EXIT 
(NIL) 

It  GO  to  orocedurename ' 

(<T1  T3>) 

//  IF  condition  thenclause  elseclause  — 

( <11  T2  T3  T4>) 

If  PERFORM  pprforrabody  perf ormcontrols 
((if  T3  tnen  (for  (X  R_T2) 

in 

(REVERSE  T3) 

do  R_  < ' PERFORM  X: 1  R  X:2  X:3>  finally 
(RETURN  R)) 
else  <' PERFORM  '  (0NCE$) 

T2  NIL  NIL> ) ) 

II  READ  filename  endcondition 
( < T 1  12  T3>) 

//  STOP  RUN  assertion 
( <  T 1  T3>) 

It  NRITE  recordname 

(  <  T 1  12  >  ) 

It  assertion 

( 1 1 ) 

It  corrop  corresponding  identifier  connector  identifier  rounded 

errorcondition 

(<T1  13  To  T6  T7>) 


sentence  2 

It  COMPUTE  computetarget  =  expression  errorcondition 
((for  X  in  T2  collect  < !  X  T4  T5>)) 

It  GO  to  procedurenames  DEPENDING  on  expression 
((for  I  to  (LENGTH  T3) 
collect 

( <  IF  <  EQ$  T6  I>  < 'GO  (CAR  (NTH  T3  I)) 

>  'NEXT  >))) 

It  OPEN  iotype  filenames 

((for  X  in  T3  collect  <T2  X>)) 
it  MOVE  expression  TO  identifiers 

((for  X  in  T4  collect  <'SET$  X  T2  NIL>)) 
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If  .io VE  corresponding  identiiier  TO  identifiers 

((for  X  in  T5  collect  <  MOVECORSoGPONDINGI  T3  X>)) 
it  ADD  expressions  (JIVING  compute  target  errorcondition 
((for  X  in  T4  collect  <!  X  C'PLUS  !  T2>  T5>)) 
it  ADD  expressions  TO  computetarget  errorcondition 
((for  X  in  T4  collect  <!  X  < ' PLUS  X:2  !  T2>  T5>)) 
if  SUdTkACT  expressions  FRCM  computetarget  errorcondition 

((for  X  in  14  collect  <!  X  X'SUBTRACI  X: 2  C'PLUS  !  T2>>  T5>)) 

If  SUBTRACT  expressions  FROi-l  expression  GIVING  computetarget 
errorcondition 

((for  X  in  To  collect  <i  X  C'SUBTRACT  T4  < ' PLUS  !  T2>>  T7>)) 
it  riuLIIPLX  expression  di  computetarget  errorcondition 
((for  X  in  T4  collect  <!  X  C' TIMES  12  X: 2>  T5>)) 
if  riJLIiPLX  expression  Bf  expression  GIVING  computetarget  errorcondition 

((for  X  in  To  collect  <!  X  <  TIMES  12  T4>  T7>)) 
it  DIVIDE  expression  INfo  computetarget  errorcondition 
((for  X  in  14  collect  <!  X  <  DIVIDE  X:2  T2>  T5>)) 
it  DIVIDE  expression  INfu  expression  GIVING  computetarget  errorcondition 

((for  X  in  T5  collect  <!  X  C'OIV IDE  T4  T2>  T7>)) 

It  DIVIDE  expression  Bi  expression  GIVING  computetarget  errorcondition 
((for  X  in  To  collect  <!  X  C'DIVIDE  f2  T4>  T7>)) 


sentences 
It  sentencel  . 

(<T1>) 

it  sentencel  .  sentences 
( <T1  !  T3» 
it  sentence2  . 

(ID 

It  sentence2  .  sentences 
(<!  fl  !  I3> ) 


simplecondition 

It  expression  is  ro  1  at  ionoperator  expression 
(<T3  II  14  ;> } 


suoscriptl 1st 
it 

( Nlu) 

It  (  subscripts  ) 
(  12) 


75 


'MTS* 


subscripts 

#  expression 

( <  T 1  >  ) 

#  expression  ,  subscripts 
( <T 1  !  T3>) 


than 

If 

(NIL) 
#  THAN 
(NIL) 


thenclause 
#  NEXT  SENTENCE 
( 'NEXT) 

If  semi  sentence 

( T2 ) 


tnru 

#  THROUGH 
(NIL) 

If  THRU 
(NIL) 


to 

If 

(NIL) 
If  TO 
(NIL) 


varying 
If  AFTER 

(  'VARYING) 
If  VARYING 
( 'VARYING) 
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V  THE  ASSERTION  LANGUAGE  FOR  COBOL  VERIFICATION 


A .  General 

The  deductive  systeir,  in  a  program  verification  system  will  attempt 
to  prove  the  validity  of  a  formula  in  first-order  logic,  the  language  of 
mathematical  theorems.  When  one  builds  a  formal  mathematical  system, 
one  starts  with  axioms  and  attempts  to  prove  theorems  based  .on  them.  In 
program  verification,  the  axioms  are  the  semantics  of  the  programming 
language,  the  program,  and  the  assertion  language.  The  theorem  states 
that  the  program  is  correct  with  respect  to  the  assertions. 

Thus,  the  assertion  language  must  be  the  language  of  mathematics 
(in  this  case  first-order  logic,  integers,  and  real  numbers)  plus  some 
constructs  that  apply  directly  to  COBOL.  We  have  used  very  few  of  the 
latter--only  those  that  deal  with  arrays,  truncation,  rounding,  and  over¬ 
flow  in  COBOL  data  items. 

We  believe  that  the  inclusion  of  more  language-oriented  constructs 
in  the  assertion  language  will  shorten  the  assertions,  making  them  easier 
to  read  and  write,  and  will  also  simplify  proof.  In  the  last  section,  we 
describe  some  ideas  in  that  direction  that  have  not  been  implemented. 

3 .  Basic  Assertion  Language 

There  are  three  elements  of  the  basic  assertion  language: 

(1)  First-order  logic  witn  equality 

(2)  Real  and  integer  arithmetic  operators  aixl  relations 

(3)  User-defined  functions  and  predicates. 

First-order  logic  contains  the  quantifiers  V,  3;  the  connectives 
A,  v,  —i,  3;  the  equality  symbol  =;  and  the  symbols ,  predicates ,  and  functions 
used  in  the  logical  formula.  The  LISP  function  names  for  the  quantifiers 
and  connectives  are,  respectively:  FORALL,  EXISTS,  AND,  OR,  NOT,  IMPLIES, 
and  EQ.  Often  basic  set  theory  is  useful  in  connection  with  first-order 
logic . 

The  operations  on  arithmetic  items  are  simply  +,  *f  /f  and  unary 
minus  (and  exponentiation,  logarithms,  modulo  arithmetic).  The  relations 
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aie  simply  =  ,  ¥ ,  >  ,  and  < .  All  axioms  on  these  operations  and 

relations  apply  (e.g.,  commutativity  and  transitivity).  The  LISP  function 
symbols  for  the  arithmetic  and  relational  operators,  respectively,  are  ■ 
PLUS,  SUBTRACT,  TIMES,  DIVIDE,  MINUS,  EQ,  NEQ,  GT,  GTQ,  LTQ,  and  LT. 

Other  constructs,  such  as  conditional  expressions  (from  Algol  60)  - 
are  also  used.  An  example  of  the  use  of  a  conditional  expression  is 

x  =  if  b  then  y  else  z, 

and  this  translates  to  the  logical  formula 

(b  3  x  =  y)  A  (^  b  =5  x  =  z). 

facility  for  the  user  to  define  functions,  predicates,  and  syn¬ 
tactic  constructs  is  also  useful.  In  this  context,  all  special  constructs 
relating  specifically  to  COBOL  could  be  formally  defined.  Some  strict 
laws  of  definition  (such  as  those  in  Reference  26)  should  be  used  in 
creating  new  def init ions. so  that  the  soundness  of  any  proofs  based  on 
the  definitions  is  guaranteed. 

The  rules  of  inference  are  the  basic  ones  for  first-order  logic  (e.g,, 

modus  ponens)  .  Other  "rules"  can  be  derived  as  theorems. 

C ,  Special  Functions  for  COBOL 

The  special  functions  that  we  have  used  in  our  assertion  language  are 
concerned  with  particular  features  of  COBOL  arrays  and  numeric  data  items. 
These  functions  are  described  in  the  following  paragraphs. 

The  SELECT  function  for  array  access  is  briefly  described  in  Section 
III.  It  has  no  definition,  except  that  SELECT(A.I)  returns  the  Ith  value 

of  the  array  A.  Its  value  is  changed  via  an  array  assignment  CHANGE (A ,  I, 

th  ' 

which  changes  the  value  of  the  I  element  of  the  array  A  to  V.  Its 

formal  semantics  is  described  in  terms  of  the  following  Hoare  axiom  [8]: 

PfCHANGE (A , I , e) }Q  = 

P  Tb qSELECT (A , x) 

if  x  =  I  then  e  else  SELECT ( A, x) 


V), 
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This  means  that  when  a  single  value  of  array  A  changes  (the  I  value), 

th 

a  conditional  substitution  Is  made  for  the  I  value  of  the  array  only. 
However,  for  a  given  array  access  SEL£CT(A,x),  where  x  Is  an  arbitrary 
expression,  it  may  not  be  known  at  verification  time  whether  or  not  x 
is  equal  to  I.  Thus,  the  above  conditional  expression  must  be  substituted 
into  Q  for  every  Instance  of  SEL£CT(A,x).  We  can  represent  the  size  of 
the  array  A  by  the  function  LENGTH(A). 

Two  assertion-language  functions  are  associated  with  assignments 
to  numeric  data  items.  In  a  normal  assignment  statement,  truncation 
takes  place  so  that  the  new  value  of  the  receiving  data  item  "fits"  its 

PICTURE  specification.  In  an  arithmetic  statement  with  the  ROUNDED  option, 

rounding  of  the  least  significant  digits  takes  place  instead  of  truncation. 

In  both  operations,  the  most  significant  digits  will  be  lost  if  the  abso¬ 

lute  value  of  the  item  is  "too  big"  for  its  picture  specification.  We 
supply  two  functions,  TRUNCATE  and  ROUND,  to  perform  these  operations; 
both  functions  take  a  value  and  a  PICTURE  specification  as  an  argument, 
and  return  a  new  value.  For  example, 

TRUNCATE  (123.  16,  999V  9)  -  123.4 

ROUND (123 . 46 ,  999V9  )  -  123.5 

TRUNCATE (-1234. 56,  S999V39)  =  -234.56 

ROUND (-234.  56,  999V99)  234.56 

We  define  ROUND  and  TRUNCATE  in  terms  of  primitive'  and  i n te rmed la t e-li ve  i 
constructs,  and  then  define  the  intermediate-level  tonstrui  ts  in  terms  ej 
the  primitives  presented  here: 

ABS(v)  absolute  value  of  v 

DECIMALDIGITS (p)  -  number  of  digits  to  the  right  of  the  virtual 
decimal  point  of  p 

TOTALDIGITS (p)  -  total  number  of  digits  In  p 
MOD (v 1 , v 2 )  -  vl  mod  v2 

In  this  case,  v  is  a  value  and  p  is  a  PICTURE  specification.  We  define 
TRUNCATE  and  ROUND  as  follows: 
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TRUNCATE  (v ,p)  = 

if  ABS(v)  >  MAXVAL(p) 

then  MAXVAL(p)  *  PSIGN(v.p) 
else  (ABS(v)  -  EXTRADIGITS (v,p))  *  PSIGN(v,p) 

ROUND (v,p)  = 

i£  ABS(v)  >  MAXVAL(p) 

then  MAXVAL(p)  *  PSIGN(v,p) 
else  if  EXTRADIGITS (v , p)  £  .5  *  MINVAL(p) 

then  (ABS(v)  -  EXTRADIGITS (v , p)  +  MINVAL(p))  * 

PSIGN(v , p) 

else  (ABS(v)  -  EXTRADIGITS (v ,p))  *  PSIGN(v,p). 

The  following  is  a  description  of  the  intermediate-level  functions: 

EXTRADIGITS (v , p)  =  the  absolute  value  described  by  the  least 
significant  digits  left  over  after  "fitting"  into 
the  PICTURE  specification  described  by  p 

MAXVAL(p)  -  the  maximum  absolute  value  permitted  by  p 
MINVAL(p)  =  the  minimum  nonzero  absolute  value  permitted  by  p 
PSIGN(v,p)  -  the  sign  of  v  when  it  "fits"  into  p. 

Their  formal  d<  f ini t ions  are  as  follows: 


EXTRADIG  I  TS  (v  ,p)  =■ 

MOD  CARS  (v)*iODECWWLDICITS(p)  10T0TALDIGITS(P))/10DECIMALDIGITS(P) 


MAVVAT (p) 
MINVAh(l')  -  Hi 


(  UjTOTAU)IGITS(p) _  /10DECIMALDIGITS(p) 
-DEC IMALDIGITS (p) 


PS!  ON  (\  ,  p)  -  if  "s'  e  p  a  v  <r  0  then  -1 
,  Iso  1 

V  sfai.i'  assert  ion  language  construct  defined  above,  MAXVAL(p),  can 
rh  f<  -t.  i  n<  ■•.hi'ihci  or  not  a  SIZE  ERROR  has  occurred:  If  the  absolute  value 
of  .n  arithmetic  operation  exceeds  MAXVAL(p),  where  p  is  the  PICTURE  speci¬ 
fication  of  the  destination. 


Bast’d  on  the  above  formal  definitions,  we  can  develop  "rules  of 
inference"  <n r  lemmas)  that  allow  proofs  of  assertions  containing  such 
funci ions. 
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Here  is  an  example  of  how  such  functions  are  used  in  assertions, 
and  how  rules  of  inference  can  be  used  in  simplification  and  proof.  Let 
the  PICTURE  specifications  of  the  variables  A  and  B  be  999  and  99,  res¬ 
pectively.  Then  the  verification  condition  for  the  statement  "MOVE  B  TO  A 
could  be  described  as  follows: 

PjMOVE  B  TO  A}Q  s 
P  ^  ^TRUNCATE (B , 999 ) . 

Since  it  is  known  that  0  ^  B  i  99,  because  of  its  PICTURE  specification, 
it  therefore  "fits"  into  A  without  modification.  This  suggests  a  rule 
of  inference:  If  the  PICTURE  specif ication  of  the  destination  in  a  MOVE 
operation  subsumes  the  PICTURE  specification  of  the  source,  then  the 
TRUNCATE  function  need  not  be  used  in  the  verification  condition.  The 
verification  condition  then  simplifies  to 

PlMOVE  B  TO  A]Q  5 

P^OJ  . 

As  a  second  example,  let  us  suppose  that  A  and  B  have  PICTURE  specifi¬ 
cations  as  above,  and  tnat  C  has  a  PICTURE  specification  of  99.  Then 
the  verification  condition  for  the  statement "COMPUTE  A  =  B  +  C"  would  be 
as  follows: 

PlCOMPUTE  A  -  B  +  c]q 

p  qa 

TRUNCATE (B+C , 999 )  . 

Since  the  maximum  value  for  the  sum  of  B  and  C  Is  198,  and  minimum  value 
is  0,  then  using  the  last  rule  (generalized  to  arithmetic  expressions)  we 
get 

P [COMPUTE  A  -  B  +  CjQ  ; 


We  present  several  examples  of  assertions  that  can  be  made  about 
COBOL  programs.  To  say  that  an  array  A  is  sorted  in  ascending  order,  we 
write 
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Vx(l  £  X  =£  LENGTH (A)-l  =5  A(X)  *  A(X+1))  , 

or  in  LISP  form 

(FORALL  X 

(IMPLIES 

(AND 

(LTQ  1  X) 

(LTQ  X  (SUBTRACT  (LENGTH  A)  1))) 

(LTQ 

(SELECT  A  (X)) 

(SELECT  A  ((PLUS  X  1)))))) 

If  we  wish  to  state  that  a  particular  value  C  occurs  in  array  A,  we 
write 


3X(1  £  X  ^  LENGTH (A)  A  A(X)  =  C)  , 

or  in  LISP  form 

(EXISTS  X 

(AND 

(AND 

(LTQ  1  X) 

(LTQ  X  (LENGTH  A))) 

(EQ 

(SELECT  A  (X)) 

C)))  . 

A  typical  input  assertion  to  a  COBOL  program  would  give  the  values  of 
the  input  files,  and  a  typical  output  assertion  would  describe  the 
relation  of  values  in  the  input  files  to  values  in  the  output  files. 

In  this  work,  where  input  files  and  output  files  are  disjoint,  this  is 
easy  to  do.  However,  in  cases  where  a  file  may“be  open  for  input  and 
output,  wc  need  a  mechanism  to  distinguish  between  the  initial  values 
and  current  values  in  the  file.  One  solution  is  to  concatenate  a 
special  character  to  the  file  name  to  denote  initial  file  values. 

D *  Abstract  Assertions  for  COBOL  Programs 

As  will  be  seen  in  the  example,  assertions  and  verification  con¬ 
ditions  for  COBOL  programs  may  be  very  long  (the  verification  conditions 
nre  much  longer  than  the  program  itself).  A  desirable  goal  of  future 
verification  research  is  to  shorten  the  verification  conditions  and 
assertions,  to  enhance  both  understandability  and  provability.  We  have 
begun  to  explore  3ome  of  these  issues,  and  describe  these  explorations 
hero.  One  way  of  doing  this  is  to  develop  primitives  for  writing  abstract 


BEST  AVAILABLE  COPY 


82 


assertions  for  COBOL  programs.  Abstract  assertions  could  make  the 
assertions  more  readable,  since  they  would  be  shorter,  but  would  they 
increase  provability?  There  is  still  some  doubt  on  that  issue.  We 
present  some  abstract  assertion  structures,  together  with  their  def¬ 
initions  and  rules  of  inference. 

In  conventional  program  proving  (including  the  approach  taken  in 
this  work),  the  assertions  deal  with  the  values  of  variables,  to  the 
exclusion  of  their  other  attributes.  This  enables  free  substitution 
of  values,  but  does  not  permit  more  powerful  inferences  to  be  made,  as 
could  be  done  when  the  other  information  is  made  available. 

The  main  area  of  examination  to  date  has  been  the  property  of 
equality.  In  conventional  equality,  the  values  of  data  items  are  con¬ 
sidered,  so  that  substitution  may  take  place.  We  propose  first  a  kind 
of  equality  between  data  items  called  "structural  equality.”  Two  data 
items  are  structurally  equal  if  and  only  if  either: 

(1)  Both  items  are  elementary  data  items  having  the  same 
PICTURE  specification  and  the  same  number  of  occurrences,  or 

(2)  Both  items  are  group  data  items 

(a)  That  have  the  same  number  of  immediate  descendants,  and 

(b)  Whose  corresponding  descendants  are  structurally  equal. 

This  is  a  static  property  of  COBOL  data  items,  but  the  programmer  may 
wish  to  assert  such  a  property  in  the  program  test.  This  definition 
will  be  used  In  later  assertion  structures. 

We  next  define  the  notion  "strong  equality."  Two  data  items  are 
strongly  equal  if  and  only  if  either: 

(1)  Both  items  are  elementary  data  items  that  are  structurally 
equal  and  whose  values  are  equal,  or 

(2)  Both  items  are  group  data  items  that  are  structurally  equal 
and  whose  corresponding  descendants  are  strongly  equal. 

Both  strong  and  structural  equality  are  powerful  properties  to  be  asserted 
about  tree-structured  records. 
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There  is  a  notion  or  equality  connected  to  the  MOVE  statement, 
called  "weak  equality,"  a  noncommutatlve  relation  among  data  items. 

Let  A  and  B  be  data  items,  and  let  PICB  be  the  PICTURE  specification 
of  B.  A  is  said  to  be  weakly  equal  to  B  if  and  only  if  either: 

(X)  Both  items  are  elementary  data  items  and  B  «  TRUNCATE (A , PICB) , 

or 

(2)  Both  items  are  group  data  items 

(a)  That  have  the  same  number  of  immediate  descendants,  and 

(b)  Such  that  if  AI  is  an  immediate  descendant  of  A  and  BI 
is  the  corresponding  immediate  descendant  of  B,  then 
AI  must  be  weakly  equal  to  BI . 

A  similar  kind  of  equality  related  to  the  MOVE  CORRESPONDING  statement 
may  also  bo  defined,  called  "corresponding  equality"  (this  notion  is. 

not  defined  here). 

A  verification  condition  generator  would  have  to  know  how  to  process 
assertions  containing  these  abstract  constructs,  because  some  COBOL  opera¬ 
tions  preserve  these  relations  and  other  operatlons~lnvalidate  the  relations. 

The  above  framework  can  be  extended  to  cover  arbitrary  relations  on 
data  items.  Although  this  mechanism  is  a  good  way  of  relating  properties 
of  records,  a  mechanism  for  relating  records  within  a  file  and  the  records 
of  two  different  files  would  also  be  useful. 

These  mechanisms  are  useful  simply  because  many  COBOL  programs  entail 
the  movement  of  data  without  extensive  arithmetic  operations  on  it.  The 
abstract  assertions  described  above  capture  some  of  the  notions  involved 
in  data  movement.  One  additional  comment  is  that  programmers  who  structure 
their  programs  so  that  the  above-mentioned  properties  hold  will  probably 
be  increasing  the  reliability  of  their  programs.  The  effects  of  abstract 
assertions  for  COBOL  on  proof  will  bo  illustrated  in  future  work. 

E .  Conclusions 

We  have  shown  that  the  assertion  language  for  COBOL  can  be  extremely 
simple.  However,  the  reliance  on  a  simple  assertion  language  may  make  the 
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assertions  difficult  to  read,  and  the  proofs  unduly  complex.  Thus,  an 
assertion  language  should  be  extensible  so  as  to  permit  the  abstract 
program  properties  to  be  stated  concisely.  The  exact  nature  of  the 
extensions  to  be  chosen  is  a  matter  for  future  research. 
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VI  SEMANTICS  OF  THE  COBOL  SUBSET 


A.  Introduction 

Semantics  of  a  programming  language  can  never  be  completely  separated 
from  its  syntax.  Thus,  in  Section  IV,  the  transduction  grammar  for  the 
CSV  has  some  relation  to  the  semantics  of  the  language  (e.g.,  the  fact  that 
MOVE,  COMPUTE,  and  ADD  are  all  related,  influenced  the  decision  to  trans¬ 
duce  them  to  the  common  primitive  SET$).  However,  most  of  the  semantic 
issues  are  left  unincerpreted  since  we  have  not  yet  defined  ihe  semantics 
of  Transduced  COBOL.  We  define  these  semantics  by  describing  each  of  the 
primitives  in  Transduced  COBOL  in  terms  of  a  simple  language  involving 
only  assignments,  tests,  and  branches.  The  semantics  of  this  simple  lan¬ 
guage  are  in  turn  described  by  the  way  in  which  verification  conditions 
are  generated  for  programs  in  it.  Thus,  the  semantics  of  the  COBOL  sub¬ 
set  are  contained  in  the  description  of  the  operation  of  the  Posttrans¬ 
duction  Processor  and  the  Verification  Condition  Generator.  Both  pro¬ 
grams  have  been  abstractly  described  in  Section  III  of  this  report.  In 
this  section,  we  present  a  more  detailed  description  of  both  programs, 
followed  by  a  discussion  of  some  research  issues  in  verification  con¬ 
dition  generation. 

B.  Posttransduct  ion  Processing 

Posttransduction  processing: 

(1)  Transforms  the  label  structure  of  the  program  so 
that  paragraph  names  are  unique.  In  COBOL,  two 
different  sections  may  have  paragraphs  of  the  same 
name.  The  section  structure  may  then  be  taken  out. 

(2)  Forms  a  list  of  labels  with  their  corresponding 
assertions  for  later  use  by  the  path  analyzer  (part 
of  the  verification  condition  generator)  for  pro- 
ces: ing  GO  TO  statements. 

(3)  Eliminates  the  paragraph  structure  of  the  program. 

A  copy  of  the  program,  after  step  (1),  has  been  saved 
so  that  labels  can  be  processed  correctly. 
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Scans  each  sentence  in  the  program  and  translates  it  into 
the  simple  language  to  generate  a  verification  condition. 

The  sentences  transformed  are: 

(a)  PERFORM  statements 

(b)  All  I/O  statements 

(c)  All  assignment  statements 

(d)  All  CORRESPONDING  statements. 

These  operations  need  knowledge  of  the  symbol  table  as  well  as  knowledge 
of  the  transduced  program.  We  now  present  some  simple  examples  of  the 
kind  of  operations  performed  in  posttransduction  processing. 

Suppose  that  we  start  with  a  very  simple  COBOL  program  as  follows: 

PROCEDURE  DIVISION. 

51  SECTION. 

PI . 

(ASSERT  (GTQ  X  5)). 

ADD  1  TO  X. 

P2  , 

ADD  2  TO  X. 

52  SECTION. 

P3  . 

ADD  1  TO  X. 

PI  . 

ADD  1  TO  X. 

(ASSERT  (GTQ  X  10)).  (VI-I) 

Its  transduced  form  would  be: 

JPROCEDURFDIY I  SIGNS  (SECTIONS  SI  (PARAGRAPHS  PI 

(ASSERT  (GTQ  X  5)) 

(SETS  X 

(PLUS  X  1) 

NIL)) 

(PARAGRAPHS  P2  (SETS  X 

(PLUS  X  2) 

NIL))) 

(SECTIONS  S2  (PARAGRAPHS  P3 

(SETS  X 

(PLUS  X  1) 

Nil  )) 

(PARAGRAPHS  PI  (SETS  X 

(PLUS  X  1) 

NIL) 

(ASSERT  (GTQ  X  lo] 
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The  first  stage  of  posttransduction  processing  creates  unique  labels 
as  follows: 

[>ROCEDUREDIVISION$  (SECTION$  SI  (PARAGRAPHS  (PI  SI) 

(ASSERT  (GTQ  X  5)) 
(SET$  X 

(PLUS  X  1) 

NIL)) 

(PARAGRAPHS  (P2  SI) 

(SETS  X  (PLUS  X  2) 

NIL))) 

(SECTIONS  S2  (PARAGRAPHS  (P3  S2) 

(SETS  X 

(PLUS  X  1) 

NIL)) 

(PARAGRAPHS  (PI  S2) 

(SETS  X  (PLUS  ;  1) 

NIL) 

(ASSERT  (GTQ  X  10] 


Notice  how  the  two  paragraphs  named  PI  may  now  be  distinguished  because 
their  section  names  have  been  joined  with  them  into  a  list.  The  sections 
are  then  taken  out: 

f( PARAGRAPHS  (PI  SI) 

(ASSERT  (GTQ  X  5)) 

(SETS  X  (PLUS  X  1) 

NIL)) 

(PARAGRAPHS  (P2  SI) 

(SETS  X  (PLUS  X  2) 

NIL)) 

(PARAGRAPHS  (P3  S2) 

(SETS  X  (PLUS  X  1) 

NIL)) 

(PARAGRAPHS  (PI  S2) 

(SETS  X  (PLUS  X  1) 

NIL) 

(ASSERT  (GTQ  X  10] 


In  the  second  stage,  all  paragraph  names  associated  with  assertions  are 
listed  to  be  used  later  in  processing  GO  TO  statements.  The  list  is  not 
needed  for  this  program  but  is  made  anyway.  The  list  is: 

(((PI  SI)  ASSERT  (GTQ  XX  10)))  . 


The  paragraph  structure  of  the  program  can  now  be  eliminated  as  follows: 
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((ASSERT  (GTO  X  5)) 

(SET$  X  (PLUS  X  1) 

NIL) 

(SET$  X  (PLUS  X  2) 

NIL) 

(SETS  X  (PLUS  XI) 

NIL) 

(SETS  X  (PLUS  X  1) 

NIL) 

(ASSERT  (GTQ  X  10))) 

Now  each  sentence  in  the  program  is  translated  into  its  equivalent  form 
in  a  simpler  language  called  "Posttransduced  COBOL."  The  example  pro¬ 
gram  translates  to: 

((ASSERT  (GTQ  X  5)) 

(ASSIGN  X  (TRUNCATE  999  (PLUS  X  1))) 

(ASSIGN  X  (TRUNCATE  999  (PLUS  X  2))) 

(ASSIGN  X  (TRUNCATE  999  (PLUS  XI))) 

(ASSIGN  X  (TRUNCATE  999  (PLUS  XI))) 

(ASSERT  (GTQ  X  10))) 

In  this  case  the  assignment  statements  were  augmented  to  include  trun¬ 
cation  (note  that  the  PICTURE  specification  of  X  Is  999). 

We  now  present  examples  of  how  other  statements  in  the  language  are 
translated  into  posttransduced  form.  The  most  complicated  is  the  PERFORM 
statement.  We  have  decided  to  handle  the  paragraphs  that  make  up  the 
body  of  the  PERFORM  statement  by  expanding  them  in-line.  Another  way  to 
handle  the  body  of  a  PERFORM  statement  is  to  treat  it  as  a  procedure  call, 
with  entry  and  exit  assertions  describing  the  effects  of  the  PERFORM  state¬ 
ment  .  There  is  a  clear  trade-off  here:  in  simple  programs  (without  many 
PERFORM  blocks  that  are  repeatedly  used)  the  expansion  method  is  pref¬ 
erable,  because  there  are  fewer  proofs  to  generate;  in  more  complex  pro¬ 
grams  the  procedure-call  method  is  preferable,  because  the  proof  of  the 
PERFORM  body  need  only  be  done  once  even  if  the  PERFORM  block  is  used  many 
times.  The  most  interesting  options  are  the  PERFORM  VARYING  and  PERFORM 
n  TIMES  because  they  are  loops  that  must  be  translated  into  assignments, 
tests,  and  branches.  For  example,  the  COBOL  statement 

PERFORM  PI  VARYING  I  FROM  1  BY  1 

UNTIL  I  >  N  (ASSERT  (PI))  . 

would  be  translated,  as  shown  in  Figure  VI-1.  There  is  an  initialization 
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1  >  N 


True 


Next  Statement 
After  PERFORM 


False 


> 

Q 

O 

m 

OF  PI 

1-1  +  1 

S  A-3967-9 


FIGURE  IV- 1  TRANSLATION  OF  "PERFORM  PI  VARYING 
1  FROM  1  BY  1  UNTIL  I  >  N  (ASSERT 
(P  l»" 
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of  I,  a  list  on  I  and  the  increment  of  I.  The  COBOL  statement 


PERFORM  PI  N  TIMES. 

would  also  be  translated  in  the  same  way.  As  a  detailed  example,  let 
us  examine  the  following  COBOL  program 


PROCEDURE  DIVISION. 

PI. 

MOVE  0  TO  SUM. 

PERFORM  P2  VARYING  I  FROM  1  BY  1 

UNTIL  I  >  N  (ASSERT  (GTQ  SUM  0)). 
STOP  RUN  (ASSERT  (GTQ  SUM  0)). 

P2 . 

ADD  A (I)  TO  SUM. 


Its  transduced  form  is  as  follows: 

[PROCEDURE D IV I S 1 0N$  (SECTIONS  FIRSTSECTION 

[PARAGRAPHS  PI  (SETS  SUM  0  NIL) 
(PERFORM 
VARYING 
(DOS  P2  P2) 

(Ill  (GT  I  N)) 

(ASSERT  (GTQ  SUM  0))) 
(STOP  (ASSERT  (GTQ  SUM  0] 

(PARAGRAPHS 

P2 

(SETS  SUM  (PLUS  (SELECT  A  (I)) 

SUM) 

NIL] 

After  posttransduction  processing  it  looks  like  this: 

[(ASSIGN  SUM  (TRUNCATE  999  0)) 

[BLOCK  (ASSIGN  I  (TRUNCATE  99  1)) 

(ASSERT  (GTQ  SUM  0)) 

(IF  (GT  I  N) 

(ENDPERFORM) 

(NEXT)) 

(ASSIGN  SUM  (TRUNCATE  999  (PLUS  (SELECT  A  (I)) 

SUM))) 

(ASSIGN  I  (TRUNCATE  99  (PLUS  I  1))) 

(LOOPASSERT  (ASSERT  (GTQ  SUM  0] 

(STOP  (ASSERT  (GTQ  SUM  0))) 

(ASSIGN  SUM  (TRUNCATE  999  (PLUS  (SELECT  A  (I)) 

SUM] 
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Notice  how  the  body  of  P2  has  been  expanded  and  the  initialization, 
increment,  and  test  have  been  included.  The  loop  assertion  appears  in 
two  places:  at  the  beginning  of  the  loop,  and  as  part  of  the  loop 
(in  the  LOOPASSERT  statement).  The  statement  ENDPERFORM  indicates  that 
control  is  to  be  passed  to  the  statement  following  the  PERFORM  state¬ 
ment.  If  P2  had  more  than  one  statement,  then  the  expansion  would  be 
in  terms  of  a  list  headed  by  the  keyword  BLOCK,  indicating  multiple  state¬ 
ments  . 

All  input-output  statements  must  be  translated  to  array  accesses. 

A  sequential  file  F  is  represented  as  a  set  of  arrays  ( _ .ARRAY) — one  for 

each  elementary  item  in  the  record  description.  There  is  an  array  pointer 
(F. INDEX)  that  indicates  the  record  currently  being  processed.  A  variable 
F. LENGTH  indicates  the  number  of  records  in  the  file.  READ  and  WRITE 
simply  perform  MOVE  operations  from  the  array  to  and  from  the  file's  record 
in  the  program  and  increment  the  array  pointer.  OPEN  and  CLOSE  simply  set 
the  array  pointer.  For  example,  the  COBOL  statement 


OPEN  INPUT  X. 

has  as  transduced  form 

(OPENINPUT$  X) . 

In  posttransduction  processing  it  becomes 

(SET$  X. INDEX  0). 

Note  that  X . INDEX  is  the  array  pointer.  The  COBOL  statement 

READ  X  AT  END  GO  TO  PI. 

transduces  to 

(READ  X  (GO  PI)). 


Suppose  that  Y  is  the  record  for  file  X,  and  the  data  declaration  for 
Y  is  as  follows: 


01  Y. 

02  Z1  PICTURE  999. 

02  Z2  PICTURE  S9V999. 
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Then  there  are  to  be  two  arrays:  Zl. ARRAY  and  Z2 .ARRAY.  The  number 
of  records  in  the  file  is  represented  by  the  variable  X. LENGTH.  The 
intermediate  form  of  the  statement  before  translation  of  the  assign¬ 
ment  statements  is 

(SET$  X. INDEX  (PLUS  X. INDEX  1)) 

(IF  (GT  X. INDEX  X. LENGTH) 

(GO  PI) 

(NEXT)  ) 

(SET$  Zl  (SELECT  Zl .ARRAY (X. INDEX)) 

(SET$  Z2  (SELECT  Z2 .ARRAY (X. INDEX) ) . 

Note  that  the  AT  END  option  is  a  test  to  see  whether  the  current  index 
is  greater  than  the  number  of  records. 

Assignment  statements  are  transformed  by  using  the  function 
TRUNCATE (p,e)--p  is  a  PICTURE  specification  and  e  is  an  expression — to 
truncate  the  assigned  expression  to  the  PICTURE  specification  of  the 
destination  data  item.  If  the  assignment  statement  has  the  ROUNDED 
OPTION,  then  the  function  ROUND(p.e)  replaces  TRUNCATE.  The  SIZE  ERROR 
option  is  transformed  into  an  IF  statement,  testing  the  absolute  value 
of  the  expression  against  MAXSIZE(p),  where  p  is  the  PICTURE  specification 
of  the  destination.  For  example,  the  COBOL  statement 

COMPinE  X  =  Y  +  Z  ON  SIZE  ERROR  GO  TO  PI . 

transduces  to 

(SET$  X 

(PLUS  Y  Z) 

(GO  PI)) . 

Suppose  the  PICTURE  specification  of  X  is  S999V9.  Then  the  posttransduced 
form  looks  like  this: 

(IF  (GT  (ABS  (PLUS  Y  '.  )) 

999.9) 

(GO  PI) 

(NEXT)) 

(ASSIGN  X  (TRUNCATE  S999V9 

(PLUS  Y  Z))) . 

If  no  SIZE  ERROR  clause  is  specified,  there  is  no  IF  statement.  This  is 
slightly  at  variance  with  COBOL  74,  since  it  specifies  that  if  a  SIZE 
ERROR  condition  occurs  and  no  SIZE  ERROR  clause  is  specified,  then  no 
assignment  occurs.  We  intend  to  remedy  this  inconsistency  in  future  work. 


The  CORRESPONDING  operations  have  a  particularly  interesting  trans 
formation  to  posttransduced  form.  The  definition  of  MOVE  CORRESPONDING 
A  TO  B  is  as  follows: 

(1)  If  A  is  an  elementary  data  item,  MOVE  A  TO  B. 

(2)  Otherwise  take  all  immediate  descendants  of  A  that  have 
the  same  name  as  any  immediate  descendants  of  B,  and  put 
them  in  set  S.  For  all  elements  X  in  S,  MOVE  CORRESPONDING 
X  OF  A  TO  X  OF  B. 

As  an  example,  suppose  A  and  B  have  the  following  data  declarations: 

01  A. 

02  C. 

03  E  PICTURE  9 99. 

02  D. 

03  G  PICTURE  999. 

02  F  PICTURE  999. 

01  B. 

02  C. 

03  G  PICTURE  999. 

03  E  PICTURE  999. 

02  F  PICTURE  999. 


The  statement 

MOVE  CORRESPONDING  A  TO  B. 
transduces  to 

(MOVECORRESPONDING$  A  B) . 

After  posttransduction  processing  this  becomes  the  two  statements 

(ASSIGN  (QUAL  E  C  B) 

(TRUNCATE  999  (QUAL  E  C  A))) 

(ASSIGN  (QUAL  F  B) 

(TRUNCATE  999  (QUAL  F  B))). 

C .  Verification  Condition  Generation 

The  verification  condition  generator  is  given  the  posttransduced 
COBOL  program  as  input.  Verification  condition  generation  has  two 
stages : 

(1)  Analysis  of  all  the  simple  paths  through  the  program. 

A  simple  path  is  a  program  path  that  has  an  entry 
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assertion,  an  exit  assertion  and  a  fixed  number  of  program 
statements  in  between.  A  list  of  these  simple  paths  is  re¬ 
turned  by  the  path  analyzer.  The  path  analyzer  must  have 
semantic  knowledge  of  the  following  posttransduced  statements 


(a)  IF 

(b)  GO  TO 

(c)  BLOCK  (multiple  statements  in  posttransduced  program) 

(d)  ENDPERPORM 

(e)  LOOPASSERT 
<f)  STOP 

The  statements  in  a  simple  path  are  presented  backwards 
relative  to  the  order  of  execution.  This  is  necessary 
for  the  next  stage. 

(2)  Creation  of  the  verification  condition  from  the  path 
description.  The  exit  assertion  is  pushed  backwards 
through  the  program  path.  This  involves  substition  when 
an  assignment  statement  is  encountered,  and  the  con¬ 
struction  of  implications  when  assertions  or  IF  state¬ 
ments  are  encountered.  The  final  verification  condition 
is  returned  at  this  stage. 

In  path  analysis  all  IF  statements  generate  two  possible  paths — 
one  for  instances  when  tne  condition  is  true  and  another  for  instances 
when  the  condition  is  false.  The  condition  that  holds  for  a  paticular 
path  (either  true  or  false)  becomes  part  of  the  path  as  an  argument  to 
the  IF  statement.  Thus,  the  COBOL  statements, 

COMPUTE  X  =  Y  +  Z. 

IF  X  ■  0  NEXT  SENTENCE 
ELSE  ADI)  1  to  X., 

transduced  and  posttransduced  as  follows: 

(ASSIGN  X  (TRUNCATE  999 

(PLUS  Y  Z))) 

(IF  (CT  X  0) 

(NEXT) 

(ASSIGN  X  (TRUNCATE  999 

(PLUS  X  1)))), 
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would  generate  the  two  partial  paths 


((IF  (GT  X  0)) 

(ASSIGN  X  (TRUNCATE  999 
(PLUS  Y  Z) ) ) ) 

and 

((ASSIGN  X  (TRUNCATE  999 

(PLUS  XI))) 

(IF  (NOT  (GT  X  0))) 

(ASSIGN  X  (TRUNCATE  999 

(PLUS  Y  Z))) 

for  the  true  and  false  conditions  of  the  IF,  respectively.  Note  the 
reverse  order  of  the  statements. 

A  GO  TO  statement  forms  the  end  of  a  path,  and  the  assertion  attached 
to  the  label  of  the  destination  paragraph  must  be  fetched.  That  assertion 
would  be  found  on  the  global  variable  LABELASSERTLIST  described  in  the 
previous  subsection.  For  example,  if  there  is  a  posttransduced  statement 
like  this  (paragraph  LI  occurs  only  in  section  SI) 


(GO  LI) 

and  LABELASSERTLIST  has  an  entry 

((LI  SI)  ASSERT  (LT  P  Q) ) , 

then  that  assertion  would  be  included  at  the  end  of  any  path  that  ended 
with  a  branch  to  LI. 


All  statements  appearing  in  a  BLOCK  are  simply  processed  individually. 

An  ENDPERFORM  statement  generates  the  exit  path  from  the  PERFORM.  A  LOOPASSERT 
statement  generates  the  path  around  a  PERFORM  loop.  STOP  simply  ends  that 
path . 


One  example  of  output  from  the  path  analyzer  is 


from  program  VI-1: 


[  ( (ASSERT 
(ASSIGN 
(ASSIGN 
(ASSIGN 
(ASSIGN 
(ASSERT 


(GTQ  X  10)) 

X  (TRUNCATE  999 
X  (TRUNCATE  999 
X  (TRUNCATE  999 
X  (TRUNCATE  999 
(GTQ  X  5J 


(PLUS  XI))) 
(PLUS  XI))) 
(PLUS  X  2))) 
(PLUS  XI))) 
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Since  it  is  a  straight-line  program,  there  is  only  one  path.  Another 
example  is  from  program  VI-2: 

[ ( (ASSERT  (GTQ  SOM  0)) 

(IF  (GT  I  N)) 

(ASSERT  (GTQ  SUM  0))) 

((ASSERT  (GTQ  SOM  0)) 

(ASSIGN  I  (TRUNCATE  99  (PLUS  I  1))) 

(ASSIGN  SUM  (TRUNCATE  999  (PLUS  (SELECT  A  (I)) 

SUM))) 

(IF  (NOT  (GT  IN))) 

(ASSERT  (GTQ  SUM  0))) 

((ASSERT  (GTQ  SUM  0)) 

(ASSIGN  I  (TRUNCATE  99  1>) 

(ASSIGN  SUM  (TRUNCATE  999  0] 

This  program  is  a  single-loop  program  and  therefore  has  three  paths.  The 
first  path  is  the  exit  path  from  the  program  when  the  PERFORM  is  finished. 

The  second  path  is  the  loop  path.  The  third  path  is  the  initialization 
path.  In  both  programs,  the  paths  are  listed  in  reverse  order  of  execution. 

In  verification  condition  generation  a  path  is  converted  into  a 
formula  to  be  proved.  The  formulae  for  all  the  paths  are  conjoined  together, 
yielding  the  verif ication  condition  for  the  entire  program.  The  verification 
condition  generator  moves  through  the  path  (listed  backwards  by  the  path 
analyzer)  building  the  formulae  as  it  goes.  Let  x  be  an  arbitrary  Boolean 
expression.  If  it  encounters  an  (ASSERT  x)  or  (IF  x)  and  the  formula  is  f, 
then  the  new  formula  is  (IMPLIES  x  f) .  If  it  encounters  an  (ASSIGN  V  e) , 
then  the  new  formula  has  e  substituted  everywhere  for  V. 

One  example  of  a  completed  verification  condition  comes  from  program 

VI-1 : 


(.AND 

(IMPLIES 
(GTQ  N  5) 
(GTQ 

(TRUNCATE 


999 

(PLUS  (TRUNCATE  999 

(PLUS  (TRUNCATE  999 

(PLUS  (TRUNCATE  999 

(PLUS  X  1)) 

2)) 


D) 

10))) 


1» 
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This  formula  is  valid,  because  if  X  is  no  less  than  5,  then  adding 
5  to  X  will  make  X  no  less  than  10.  The  only  difficulty  is  if  trun- 
tion  takes  place,  but  X  will  always  be  truncated  to  999.  Q.E.D. 


The  second  example  comes  from  program  VI-2: 


(AND  (IMPLIES  (GTQ  SUM  0) 

(IMPLIES  (GT  I  N) 

(GTQ  SUM  0))) 

(IMPLIES  (GTQ  SUM  0) 

(IMPLIES  (NOT  (GT  IN)) 

(GTQ  (TRUNCATE  999  (PLUS  (SELECT  A  (I)) 

SUM)) 


0))) 


(GTQ  (TRUNCATE  999  0) 


0)) 


There  are  three  conjuncts  (conditions)  to  be  proved.  The  first  condition 
(the  exit  condition)  is  trivially  true:  If  SUM  is  no  less  than  0,  then 
if  I  is  greater  than  N,  then  SUM  is  no  less  than  0.  The  second  condition 
cannot  be  met,  because  even  if  SUM  is  no  less  than  0,  adding  A(I)  to  it 
could  make  it  less  than  0.  The  third  condition  is  trivial:  0  is  no  less 
than  0.  However,  since  the  second  condition  could  not  be  met,  the  program 
could  not  be  proved  correct.  Imposing  stronger  conditions  at  the  loop  and 
initialization  points,  such  as  ^I(A(I)  ^  0),  would  enable  the  proof  of  this 
simple  program. 


Note  that  a  program  can  fail  to  be  verified  for  three  reasons: 


(1)  The  program  is  wrong--i.e.,  it  has  a  bug. 

(2)  The  input/output  assertions  (the  specifi¬ 
cations  of  the  program)  are  wrong. 

(3)  The  program  and  input/output  assertions 
are  mutually  consistent,  but  the  inter¬ 
mediate  assertions  have  been  chosen 
incorrectly . 


Only  the  programmer  (not  the  deductive  system)  can  determine  which  of 
these  is  the  reason  for  a  program's  failure  to  be  proved.  However,  a 
good  deductive  system  may  be  able  to  generate  a  counterexample  to  enable 
the  programmer  to  identify  the  trouble. 
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D.  Research  Issues  in  Verification  Condition  Generation 

(or  Posttransduction  Processing) 

All  possible  improvements  to  verification  condition  generation  (and 
posttransduction  processing)  would  be  of  one  kind:  add  knowledge  to  the 
system  to  make  the  verification  conditions  simpler.  In  other  words, 
perform  some  of  the  proof  effort  early.  The  reason  for  this  is  that  it 
may  be  easier  to  perform  some  simplification  when  the  knowledge  is  more 
readily  applicable.  For  example,  elimination  of  the  TRUNCATE  operation 
could  be  easily  performed  when  the  TRUNCATE  operator  is  inserted  (by 
means  of  a  simple  test) ;  but  when  a  deductive  system  is  in  operation, 
such  a  simplification  could  not  be  easily  made  because  knowledge  of  the 
maximum  size  of  the  source  item  would  be  lost. 

In  addition  to  ordinary  simplification,  verification  condition  gen¬ 
erators  might  be  designed  to  handle  abstract  assertions  about  COBOL 
programs  (described  in  Section  V).  To  do  this,  a  verification  condition 
generator  would  have  to  know  which  abstract  assertions  are  preserved  by 
which  program  statements. 

We  have  yet  to  determine  the  exact  nature  of  the  gain  to  be  made 
by  doing  simplification  during  the  verification  condition  generation  pro¬ 
cess.  However,  we  are  hopeful  that  it  will  yield  major  improvements  in 
the  efficiency  of  the  program  verification  process. 


VII  STRUCTURE  AND  COBOL  VERIFICATION 


A.  Introduction 

We  consider  four  aspects  of  structure  related  to  the  verification 
of  COBOL  programs : 

(1)  Use  of  structured  control  primitives 

(2)  Restrictions  on  COBOL  operations 

(3)  Use  of  data  bases  in  constructing  large  COBOL  systems 

(4)  Generalized  facilities  for  data  abstraction 

(5)  Top-down  design  and  modularity. 

All  of  these  structuring  facilities  have  the  goal  of  reducing  the  complexity 
of  the  program  by  breaking  it  up  into  manageable  units. 

B.  Structured  Control  Primitives 

The  use  of  a  limited  set  of  "well-structured"  control  primitives  in 
writing  programs  is  the  practice  commonly  known  as  "structured  programming." 
Instead  of  the  normal  COBOL  control  constructs,  the  programmer  writes  in 
a  block-structured,  lexically  nested  medium  (see  Section  II-G  on  control 
statements)  using  only  the  following  constructs  (as  an  example): 

(1)  IF  b  THEN  si  ELSE  s2 

(2)  WHILE  b  DO  si 

(3)  DO  si  UNTIL  b 

(4)  FOR  v  =  el  TO  e2  BY  e3  DO  si 

(5)  CASE  el  OF  si . sn. 

The  semantics  of  the  above  verbs  have  been  described  in  the  literature  on 
structured  programming.  In  the  above  expressions,  b  is  an  arbitrary  con¬ 
dition,  si  (for  all  i)  is  either  a  single  statement  or  a  sequence  of 
statements  preceded  by  BEGIN  and  followed  by  END,  v  is  an  arbitrary  variable, 
and  ei  (for  all  i)  is  an  arbitrary  expression.  The  resulting  programs  are 
much  easier  to  read  and,  on  the  average,  simpler  than  programs  written 
using  the  standard  COBOL  control  primitives.  By  simplicity  we  mean  having 
a  small  number  of  control  paths  through  the  program.  However,  for  any 
program  written  using  structured  programming  primitives,  an  equivalent 
program  that  is  equally  simple  can  be  written  using  the  standard  COBOL 
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control  primitives.  The  reason  for  this  is  that  the  complexity  of  pro¬ 
gram  verification  depends  on  three  variables: 

(1)  The  number  of  simple  paths  in  the  program 

(2)  The  complexity  of  the  assertions 

(3)  The  number  of  statements  per  simple  path. 

No  change  in  any  of  the  above  variables  is  made  simply  by  changing  from 
a  more  restricted  set  of  control  primitives  (the  structured  ones)  to  a 
less  restricted  one  (those  of  COBOL  74).  However,  we  endorse  the  use  of 
structured  programming  primitives,  because  they  tend  to  lead  to  simpler 
(and  thus  easier  to  verify)  programs.  We  also  endorse  the  practice  of 
training  programmers  to  write  programs  with  nested  control  schemes 
(flowcharts)  using  the  primitives  of  COBOL  74.  This  is  a  necessary  first 
step  towards  the  improvement  of  software  reliability  in  a  COBOL  job  shcp. 

C .  Res t rictlons  on  COBOL  Data  Operations 

In  the  analysis  of  COBOL  (Section  II)  and  the  presentation  of  the 
subset  (Section  IV),  we  mentioned  that  certain  data  operations  were  not 
amenable  to  verification.  They  were: 

(1)  Automatic  truncation  of  the  most  significant  digits 
on  a  NUMERIC  MOVE  operation. 

(2)  Allowing  the  compiler  to  permit  data  operations  from 
one  type  to  another  that  could  later  yield  a  type  error, 
such  as  moving  an  ALPHANUMERIC  value  to  a  NUMERIC  data 
item. 

In  the  first  case,  the  language  permits  the  programmer  to  make  a  mistake 
<e.g.,  accidentally  truncate  the  most  significant  digits)  because  it  is 
syntactically  the  same  as  a  correct  operation.  A  solution  to  this  problem 
is  to  syntactically  differentiate  a  MOVE  operation  in  which  significant 
digit  truncation  is  intended,  for  example 

MOVE  TRUNCATED  A  TO  B. 

Tn  the  second  case,  the  language  permits  an  operation  for  which  dynamic 
type-checking  should  take  place,  but  does  not.  Dynamic  type-checking, 
although  inefficient,  should  be  imposed,  and  a  special  statement  should 
be  added  to  the  language,  such  as 

MOVE  NUMERIC  A  TO  B;  ON  TYPE  ERROR  PERFORM  PI. 
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(if  A  is  non-NUMERIC  and  B  is  NUMERIC).  Just  as  READ  operations  have  the 
AT  END  clause  and  arithmetic  operations  have  the  ON  SIZE  ERROR  clause, 
so  should  the  special  MOVE  statements  have  an  ON  TYPE  ERROR  clause. 

The  suggested  restrictions  would  make  COBOL  programs  more  reliable, 
and  would  make  verification  easier  (because  the  verifier  must  check  for 
type  errors  even  if  the  run-time  system  does  not). 

D.  Data  Bases 

The  files  that  are  modified  by  a  COBOL  program  or  a  system  of  COBOL 
programs  can  be  considered  as  a  single  large  data  base.  Thus,  the  use  of 
a  data  base  management  facility  in  conjunction  with  a  system  of  COBOL 
programs,  has  received  much  attention  recently.  In  fact,  the  CODASYL  Data 

14 

Base  Task  Group  has  produced  a  structure  in  which  the  data  description 
language  is  almost  exactly  like  the  COBOL  74  DATA  DIVISION,  and  the  appli¬ 
cation  programs  for  the  data  base  are  almost  exactly  like  the  COBOL 
PROCEDURE  DIVISION. 

What  do  we  gain  by  using  this  approach?  If  one  looks  at  the  file 
layout  for  a  typical  COBOL  system  (see  Figure  VII-1),  there  are  many 
programs,  many  files,  and  some  files  that  are  shared  by  more  than  one 
program.  The  design  decisions  involved  in  the  layout  of  the  data  are 
scattered  throughout  the  ENVIRONMENT  and  DATA  DIVISIONS  of  all  the  programs. 
The  data  base  management  system  (DBMS)  approach  centralizes  all  the 
decisions  on  the  data  layout  in  the  scheme  for  the  DBMS.  The  declarations 
for  the  data  visible  to  each  program  are  the  subschemas  and  are  also  part 
of  the  DBMS.  The  subschemas  must  be  consistent  with  the  schema.  However, 
this  approach  allows  the  distinction  between  physical  data  declaration 
(in  the  schema)  and  logical  data  declaration  (in  the  subschemas).  With 
this  approach  decisions  can  be  hidden  from  the  programs  that  do  not  need 
to  know  about  it.  A  DBMS  is  a  good  tool  for  the  development  of  large 
COBOL  systems  because  it  separates  the  systems  analysis  (layout  of  data 
and  programs)  phase  of  the  system  development  from  the  coding  phase, 
something  that  has  always  been  done  in  practice  but  has  never  been  enforced 
by  the  available  automated  tools.  We  believe  that  the  DBMS  approach  will 
increase  the  reliability  of  the  systems  produced  by  using  it  (with  a  possible 
reduction  in  efficiency  depending  on  the  DBMS  system  characteristics). 
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We  anticipate  no  difficulty  in  using  the  techniques  developed  here 
for  verification  of  programs  using  the  CODASYL  DBMS.  However,  we  also 
do  not  anticipate  an  inherent  gain  in  the  ease  of  verification  simply 
from  using  a  DBMS  approach,  other  than  that  systems  designed  in  this 
method  will  be  better  structured  and  therefore  simpler.  This  is  because 
a  DBMS  approach  does  not  reduce  the  complexity  of  either  the  programs  or 
the  assertions  in  a  COBOL  system.  One  intuitive  reason  for  not  gaining 
is  that  decisions  on  data  declarations  and  representations  are  still 
shared  by  the  PROCEDURE  DIVISIONS  of  all  the  programs  in  the  COBOL  system. 

E.  Data  Abstraction  Facilities 


In  the  last  two  years,  much  attention  has  been  given  to  the  issue 

of  data  abstraction.  In  its  simplest  form  data  abstraction  associates 

a  set  of  abstract  operations  with  a  set  of  abstract  data  objects  (called 

a  type).  All  programs  wishing  to  manipulate  objects  of  an  abstract  type 

must  call  the  operations.  The  calling  programs  do  not  need  to  know  the 

representation  for  an  abstract  object,  only  its  formal  properties 

(described  in  terms  of  assertions  written  at  a  level  of  abstraction 

appropriate  to  the  abstract  objects  being  manipulated).  Thus,  for  example, 

the  users  of  a  stack  need  only  know  about  the  formal  properties  of  PUSH 

and  POP  (tne  stack's  operations)  and  not  about  the  implementation  of  a 

stack  in  terms  of  an  array  (to  store  the  stack)  and  a  variable  (to  store 
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the  stack  pointer) .  Some  researchers  ’  advocate  special  languages  to 
facilitate  the  use  of  data  abstraction,  while  others1  emphasize  a  formal 
medium  for  describing  the  properties  of  a  data  abstraction.  However, 
most  researchers  agree  that  the  method  promises  to  reduce  the  complexity 
of  program  verification  for  the  following  reasons: 

(1)  The  programs  are  less  complex.  A  single-level  program 
can  be  broken  up  into  two  levels  of  simpler  programs-- 
one  level  that  manipulates  abstract  objects  and  another 
level  that  implements  them.  Since  complexity  of  programs 
is  considered  to  vary  exponentially  with  their  length,  it 
is  probably  easier  to  prove  many  simple  programs  than  a 
few  complex  ones.  There  may  in  fact  be  less  code  to  prove 
correct,  because  the  code  for  a  data  abstraction  may  have 
been  previously  duplicated,  but  the  abstraction  process  has 
put  it  all  in  one  place.  Successive  decompositions  into 
two  levels  can  lead  to  systems  with  many  levels. 
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(2)  The  assertions  are  simpler.  This  is  probably  the  most 
significant  property  of  data  abstraction.  Since  the 
abstract  assertions  typically  contain  less  information 
(implementation  variables  and  algorithms  are  hidden), 
they  are  shorter  and  thus  are  easier  to  manipulate.  On 
the  other  hand,  the  Implementation  assertions  do  not  have 
to  deal  with  how  the  abstract  resource  is  being  used  and  can 
typically  be  simpler.  For  example,  keyed  records  can  be 
implemented  either  by  a  hash  table  or  a  linked  list.  The 
abstraction  is  simply  a  function  from  keys  to  records--all 
the  information  about  links  and  hashing  functions  is  elimi¬ 
nated  from  the  higher  level. 

Data  abstraction  has  shown  some  benefits  in  practical  system  design. 

2  21 

In  another  SRI  project  ’  a  general-purpose  operating  system  (whose 
major  design  goal  is  verifiable  security)  was  designed  using  a  formal 
methodology  based  on  data  abstraction.  The  operating  system  has  13 
levels  of  data  abstraction.  A  major  question  is  whether  the  kinds  of 
systems  typically  designed  using  COBOL  are  amenable  to  data  abstraction. 
Operating  systems  have  abstractions  such  as  virtual  memory  segments ,  file 
directories,  and  processes;  but  it  seems  that  no  such  abstractions  are 
visible  within  COBOL  systems.  More  research  must  be  done  on  this  matter 
to  determine  whether  COBOL  programs  can  take  advantage  of  this  valuable 
technique.  If  so,  we  suggest  a  preprocessor  that  allows  the  distinction 
between  programs  that  use  a  data  abstraction  and  programs  that  Implement 
one.  The  two  kinds  of  programs  can  be  combined  in  some  manner  (perhaps 
by  macro  expansion)  before  the  system  is  run. 

Many  sophisticated  languages  (including  COBOL)  have  some  data  abstrac¬ 
tion  built  into  their  basic  facilities.  Things  such  as  indexed  sequential 
files  and  the  hiding  of  input/output  buffering  are  examples  of  data  ab¬ 
straction.  Some  of  COBOL's  facilities,  such  as  the  elementary  data  item, 
permit  abstraction,  but  are  circumvented  by  other  facilities  (such  as 
REDEFINES).  In  a  good  data  abstraction,  the  implementation  details  are 
completely  hidden  from  the  user  of  the  abstraction. 

F .  Top-down  Design  and  Modularity 

Top-down  design  is  an  embodiment  of  the  philosophy  that  says,  "When 
there  are  many  decisions  to  make  in  the  construction  of  a  program,  make 
the  most  important  ones  first."  This  is  useful  because  each  new  decision 
that  is  made  must  be  consistent  with  the  ones  made  before.  Thus,  the 
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earlier  decisions  tend  to  influence  the  later  ones,  and  not  the  reverse. 

It  would  be  unfortunate  if  the  lesser  decision  would  influence  a  more 
important  one.  Data  abstraction  is  one  embodiment  of  this  philosophy 
because  the  decision  concerning  the  formal  properties  of  a  data  abstraction 

is  made  before  the  decision  of  how  to  implement  it. 
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Top-down  design,  as  advocated  by  Dijkstra  and  Mills  begins  with 
a  statement  of  the  problem  to  be  solved,  together  with  a  very  abstract 
program  to  solve  the  problem.  The  program  typically  has  control  state¬ 
ments  interspersed  with  natural  language.  For  example,  to  sort  an  array 
of  length  N: 

for  i  +-  1  to  N-l  do 

swap  the  smallest  element  in  A[i]...A[N] 
with  A f i ] ; 

The  programmer  then  makes  successive  refinements  in  the  abstract  program, 
incorporating  new  decisions  as  they  are  made,  until  the  final  program  is 
achieved.  These  decisions  can  be  made  concerning  either  data  or  algorithms. 
This  approach  seems  useful  for  COBOL  programs  in  deciding  the  algorithms, 
but  not  the  data,  because  a  COBOL  program  typically  consists  of  many  pro¬ 
grams  operating  on  data  that  has  probably  been  decided  on  beforehand 
(unless  some  of  the  most  abstract  programs  were  done  during  the  systems 
analysis  phase).  In  general,  this  is  a  good  way  to  write  programs,  because 
it  increases  a  programmer's  understanding  of  the  programming  problem.  As 
Dijkstra  indicates,  a  programmer  doing  stepwise  refinement  can  make 
"convincing"  arguments  for  the  correctness  of  a  refinement.  If  each  refine¬ 
ment  Is  correct  and  consistent  with  the  preceding  ones,  then  the  correctness 
of  the  entire  program  can  be  inferred.  However,  it  is  impossible  to  formally 
prove  the  correctness  of  any  program  written  in  a  nonformal  medium,  such  as 
natural  language  Interspersed  with  control  statements.  Thus,  top-down 
design  shows  little  promise  in  making  COBOL  verification  easier,  except 
that  it  may  lead  to  better  programs. 

Modularity  is  an  embodiment  of  two  beliefs 

(1)  Put  all  related  design  decisions  in  one  place 

(2)  Put  all  separable  design  decisions  in  different  places. 
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The  result  is  a  set  of  clusters  of  decisions.  Each  cluster  of  decisions 
is  made  only  in  a  distinct  module  of  the  system.  Data  abstraction  is  a 
good  example  of  modularity  because  the  related  decisions  (concerning 
the  maintenance  of  a  data  abstraction)  are  all  together  in  a  related 
set  of  programs,  which  is  in  turn  separated  from  all  the  programs  that 
use  the  data  abstraction.  Just  because  a  system  is  broken  up  into  small 
programs  does  not  mean  that  it  is  modular.  For  example,  a  program  A  that 
operates  on  five  files  may  be  modularized  into  two  smaller  programs — 
one  operating  on  two  files  and  the  other  operating  on  three  files.  This 
decomposition  is  probably  modular.  However,  if  A  is  broken  up  into  two 
smaller  programs  each  operating  on  five  files,  it  may  or  may  not  be  a 
modularization.  An  attempt  to  modularize  a  large  COBOL  program  will 
yield  benefits  only  if  it  shortens  or  simplifies  the  assertions  of  the 
larger  program.  One  way  to  assist  this  is  to  describe,  for  each  module, 
the  set  of  data  items  accessed  and  modified  by  the  module.  This  may 
enable  the  verification  system  to  simplify  the  assertions  used  in  the 
correctness  proof  of  the  module. 

G.  Conclusions 

Some  structuring  disciplines  seem  especially  promising  in  decreasing 
the  cost  of  program  verification,  and  COBOL  verification  in  particular. 
Specific  progress  in  implementing  any  of  the  schemes  described  above  has 
yet  to  be  made,  and  is  the  subject  for  future  research  in  this  area. 
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VIII  AN  EXAMPLE  OF  COBOL  VERIFICATION 


A.  Description  of  Program 

In  this  section  we  present  a  COBOL  program  that  we  have  taken  through 
the  several  stages  of  machine  processing  to  generate  verification  conditions. 
One  of  the  verification  conditions  is  proved  in  its  entirety,  and  the  proofs 
of  the  others  are  sketched. 

We  have  verifier  a  payroll  program, which  is  simple  relative  to  the 
complexity  of  an  average  COBOL  program.  The  complexity  of  the  program, 
which  is  at  the  upper  bound  of  practical  program  verification,  will  be 
revealed  in  this  section.  The  number  of  relevant  cases  is  very  large, 
which  is  reflected  in  the  number  of  execution  paths  through  the  program. 

The  function  of  the  program  is  to  update  a  master  file  and  print 
the  employees'  weekly  paycheck,  given  a  master  file,  containing  the 
employees'  cumulative  payroll  information,  and  a  time  card,  giving  the 
number  of  hours  worked  in  a  week.  The  file  structure  of  the  program  is 
shown  in  Figure  VIII-1. 

The  structure  of  the  program  at  the  highest  level  is  as  follows, 
with  appropriate  paragraphs  in  parentheses: 

(1)  File  opening  and  initialization  (OPEN-FILES) 

(2)  Main  processing  loop  (LOOP) 

(3)  Files  closing  (CLEANUP). 

The  main  processing  loop  consists  of  three  parts: 

(1)  Reading  files  (READ- INPUT-MASTER  through  READ-TIME- 
CARD)  and  checking  for  end-of-file  (GO  TO  CLEANUP) 
and  file  structure  errors  (GO  TO  ERROR-ABORT) 

(2)  Processing  a  related  set  of  records  (PROCESS-RECORDS) 

(3)  Writing  the  output  records  (WRITE-OUTPUT). 

CLEANUP  and  ERROR-ABORT  terminate  the  program.  Record  processing  has 
the  following  components: 

(1)  Setting  up  the  output  master  record  (MOVE-ARRAY)  with 
possible  error  conditions  (GO  TO  ERROR-ABORT) 

Setting  up  the  paycheck  record. 


(2) 


r 


SA-3967-11 

FIGURE  VlM-1  FILE  STRUCTURE  OF  THE  EXAMPLE  PROGRAM 
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MOVE-ARRAY  sets  up  a  single  element  of  the  array  in  the  output  master 
record,  and  must  be  PERFORMed  in  a  loop.  ERROR-ABORT  terminates  the 
program. 

* 

The  program  is  shown  in  Table  VII-1  . 

B.  Assertions 

The  numbered  assertions  of  the  program  occur  in  the  following  places: 

(1)  Input  to  the  program 

(2)  The  beginning  of  the  main  processing  loop 

(3)  Normal  exit  from  the  program 

(4)  Error  exit  from  the  program--f lie  structure  error 

(5)  Error  exit  from  the  program--record  error  or  overflow 

(6)  Loop  for  moving  the  array  information. 

The  assertions  are  written  out  (by  number  as  above)  in  Table  VIII-2. 

The  input  Assertion  (1)  states  that  the  input  files  are  the  same 
length,  that  their  name  fields  correspond,  and  that  the  array  pointer 
of  each  record  is  within  bounds.  Assertions  (2),  (3),  and  (6)  use  the 
general  invariant  for  the  program,  Assertion  (7),  which  states  that  the 
input  assertion  holds  and  that  for  each  corresponding  file  record 

(1)  The  output  value  for  the  name  equals  the  corresponding 
input  value. 

(2)  The  output  gross  pay  has  been  correctly  calculated  from 
the  input  gross  pay,  the  salary,  and  the  hours  worked 
in  the  current  week. 

(3)  The  output  hours  worked  is  the  sum  of  the  input  hours 
worked  and  the  hours  worked  in  the  current  week. 

(4)  The  current  week  has  been  incremented  from  input  to 
output . 

(3)  For  all  members  of  the  weekly  hours  array  (except  the 
current  week),  the  input  value  equals  the  output  value. 

(6)  The  output  element  of  the  weekly  hours  array  for  the 
current  week  equals  the  hours  worked  this  week. 


The  tables  are  at  the  end  of  the  section. 
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This  is  the  "essence"  of  the  workings  of  the  program.  Assertion  (2) 
states  that  the  double  end-of-file  condition  has  not  occurred  and  that 
all  the  file  pointers  are  equal.  Assertion  (3)  states  that  the  double 
end-of-file  has  occurred  and  that  the  lengths  of  the  input  files  and  of 
the  output  files  are  equal.  Assertion  (6)  states  that  the  pointers  to 
the  input  files  are  one  greater  than  the  pointers  to  the  output  files, 
that  all  the  variables  moved  before  the  loop  have  been  properly  processed, 
and  that  1-1  of  the  array  elements  have  been  processed  correctly. 

Assertion  (4)  is  FALSE.  Thus,  we  must  prove  that  this  particular 
error  condition  (having  the  end-of-file  without  the  other)  never  happens. 
Assertion  (5)  states  that  either  a  rounding  error  or  a  name  correspondence 
error  has  occurred. 

C.  Transduction  and  Posttransduction  Processing 

The  transduced  PROCEDURE  DIVISION  appears  in  Table  VIII-3.  The  trans¬ 
duced  DATA  DIVISION  appears  in  Table  VIII-4. 

Posttransduction  processing  was  then  undertaken.  Several  hand- 
simplifications  were  made  after  posttransduction  processing:  the  redun¬ 
dant  statements  were  removed  (expansion  of  a  PERFORM  produces  a  block 
of  code--the  original-~that  is  never  executed);  all  unneeded  TRUNCATE 
statements  were  removed  (we  purposely  wrote  the  program  so  there  would 
be  no  truncation  on  assignment  statements);  all  redundant  qualifications 
were  removed.  The  resulting  program  appears  in  Table  VIII-5. 

D  .  V er i f icati on  Condit i on  Generation 

The  urogram  of  Table  VIII-5  has  26  simple  paths  through  it.  The 

large  number  arises  because  of  the  number  of  IF  statements  (without 

transfers)  in  the  program.  For  example,  if  there  is  a  simple  path 

from  Assertion  (2)  to  Assertion  (6)  that  has  three  IF  statements  in  it 

3 

(without  transfers),  then  there  are  eight  (2  )  possible  ways  to  take  the 
path,  depending  on  the  disposition  of  each  of  its  constituent  IF  state¬ 
ments.  When  an  IF  statement  has  a  GO  TO  in  it,  a  new  path  is  generated. 

For  the  program  under  study,  the  number  of  simple  paths  are  as  follows 
(listed  dy  source  and  destination  assertion  number): 
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1 


1-2  1 

2-3  4 

v  2-4  4 

2-5  8 

2- 6  4 

6-6  1 
6-2  1 

3- 3  1 

4- 4  1 

5- 5  1 

Fortunately  many  of  these  paths  can  be  eliminated  from  consideration, 
because  they  are  never  taken  in  actual  execution  of  the  program.  A  simple 
path  of  a  program  is  never  taken  if  and  only  if: 

(1)  The  antecedent  of  the  VC  (verification  condition  for  the 
path)  is  FALSE. 

(2)  All  paths  that  lead  to  the  beginning  of  the  path  in  question 
are  never  taken.  For  example,  two  of  the  error  conditions 
tested  for  by  the  program  check  whether  the  files  are  not  of 
the  same  length  (2-4)  and  whether  the  corresponding  NAME  fields 
are  not  equal  (2-5).  These  two  conditions  can  never  occur, 
because  Assertion  (2)  states  that  they  do  not  happen.  The 
remaining  eight  paths  are  as  follows: 

1-2  1 

2-3  1 

2- 5  1 
2-6  1 

6- 6  1 
6-2  1 

3- 3  1 

5-5  1  . 

Of  the  remaining  paths,  two  (the  last  two)  are  trivial,  because  the  input 
and  output  assertions  are  identical,  with  no  intervening  code.  Thus,  the 
VC  looks  like  P^P,  a  trivial  deduction.  The  output  of  path  analysis 
after  the  eliminatio n  of  impossible  and  trivial  paths  is  shown  in  Table 
VIII-6. 

There  is  much  to  be  learned  from  the  hand-simplifications  performed 
after  posttransduction  processing  and  path  analysis.  The  amount  of  material 
would  have  been  exceedingly  long  without  the  simplifications.  From  this 
we  conclude  that  incremental  simplification  at  all  stages  of  the  verifica¬ 
tion  process  is  useful  in  being  able  to  keep  the  volume  of  material  to 
the  level  of  understandabil ity .  We  may  also  conclude  that  the  level  of 
complexity  (before  simplification)  of  even  such  a  simple  program  is  large 
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indeed.  This  is  one  clue  to  the  complexity  of  sof tware--and  how  it  is 
related  to  the  complexity  of  program  verification. 

Simplification  could  work  in  this  example  because  the  program  was 
written  so  as  to  be  amenable  to  such  optimization  of  the  verification 
process : 

(1)  All  MOVE  statements  were  written  so  that  truncation  would 
not  be  needed. 

(2)  Most  names  in  the  program  were  chosen  to  avoid  the 
necessity  of  qualification. 

(3)  The  control  structure  of  the  program  was  well-designed 
so  that  superfluous  paths  would  not  be  taken. 

Just  as  there  are  techniques  for  writing  understandable,  modifiable  pro¬ 
grams,  there  are  also  techniques  for  writing  verifiable  programs. 

All  the  verification  conditions  (VCs)  are  not  written  because  they 
are  verbose.  However,  we  state  what  each  VC  means  and  why  it  is  true: 

(1-2)  This  V"  states  that  the  input  assertion  and 

effects  of  file  opening  (initializing  the  file 
pointers  to  0)  is  sufficient  to  prove  the  null 
(initial)  instance  of  the  program  invariant. 

This  is  true  because  no  records  have  been  processed. 

(2-3)  This  VC  states  that  if  n  records  have  been  processed 
correctly,  the  effects  generating  two  ends  of  file 
in  reading  one  input  record  guarantee  that  the  output 
assertion  is  true:  n  records  have  been  correctly  pro¬ 
cessed,  where  n  is  the  number  of  records  in  both 
input  files.  The  conclusion  is  simply  a  restatement 
of  the  hypothesis. 

(2-^)  This  VC  states  that  if  n  records  have  been  processed 
correctly,  then  the  effects  of  generating  a  SIZE 
ERROR  in  processing  the  (n+1)  record,  guarantee 
that  cither  a  NAME  mismatch  or  a  SIZE  ERROR  must  have 
occurred  in  processing  one  of  the  records. 

(2-6)  This  vr  states  that  if  n  records  have  been  processed 
correctly,  the  effects  of  correctly  processing  some 
of  the  (n+l)st  record  guarantee  that: 

(a)  n  records  have  been  orocessed  correctly 

s  1 

(b)  some  of  the  (n+1)  record  has  been  processed 
correctly 

(c )  0  elements  of  the  array  have  been  processed 
correc  t 1 v . 
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(6-6)  An  induction--if 

(a)  n  records  have  been  processed  correctly 

s  t 

(b)  some  of  the  (n+1)  record  has  beer,  processed 
correctly 

(c)  m  elements  of  the  array  have  been  processed 
correctly 

s  t 

then  the  effects  of  processing  correctly  the  (m+1) 
array  element  guarantee  (a),  (b),  and  that  (m+1) 
elements  of  the  array  have  been  processed  correctly. 

(6-2)  If 

(a)  n  records  have  been  processed  correctly 

s  t 

(b)  some  of  the  (n+1)  record  has  been  processed 
correctly 

(c)  52  elements  of  the  array  have  been  processed 
correctly 

then  the  effects  of  processing  the  remainder  of  the 
record  correctly  and  writing  the  output  files  guaran¬ 
tee  that  (n+1)  records  have  been  processed  correctly. 

E .  Proof  of  a  Verification  Condition 

We  now  sketch  the  proof  of  the  verification  condition  for  path  (6-6), 
which  is  presented  in  Table  VIII-7.  The  complete  proof  of  this  verifica¬ 
tion  condition  is  contained  in  Table  VIII-8,  and  the  rules  of  inference 
for  the  proof  are  contained  in  Table  VIII-9.  Formal  background  for  the 
proof  can  be  found  in  any  textbook  in  mathematical  logic  (e.g.,  Reference  25). 
The  structure  of  the  verification  condition  is  as  follows: 

(AND 

(IMPLIES  a 
(IMPLIES  b 

c))). 

This  is  logically  equivalent  to 

(IMPLIES  (AND  a  b) 
c) 

Thus,  we  can  assume  a  (the  long  formula)  and  b  (— >  I  >52)  in  the  proof  of  c. 

All  conjuncts  of  c,  except  the  last  one  ((FORALL  Y  ...)),  follow  direcly 
from  identical  conjuncts  in  the  formula  a.  The  important  subformula  that 
must  be  proved  is 
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(FORALL  Y  (IMPLIES  (AND  (LTQ  I  Y) 

(LTQ  Y  (SUBTRACT  (PLUS  I  1)  1))) 

(EQ  (IF  (EQ  Y  I) 

(SELECT  HOURS- WORKED- WEEKLY- IN 
(Y)) 

(SELECT  HOURS-WORKED-WEEKLY-OUT 
(Y))) 

(SELECT  HOURS-WORKED-WEEKLY- IN  (Y))))). 

This  formula  incorporates  the  semantics  of  array  assignment.  The  condi¬ 
tional  expression  (IF)  indicates  the  place  where  array  assignment  has 
taken  place.  To  prove  this  condition,  we  break  the  formula  into  two 
cases  (written  in  infix  form) 

VY(1  ...  Y  I  -  1  HOURS-WORKED-WEEKLY-OUT  (Y)  = 

HOURS-WORKED-WEEKLY-IN(Y)) 

HOURS-WORKED-WEEKLY- IN ( I )  =  HOURS- WORKED- WEEKLY- IN ( I ) 

The  first  case  follows  from  formula  a;  the  second  case  is  an  identity. 
Thus,  the  verification  condition  is  proved. 

The  other  verification  conditions  can  be  similarly  proved,  but  it 
would  be  tedious  to  do  so  here. 

F .  Cone  1  us  ions 

We  have  shown  how  the  proof  of  a  simple  COBOL  program  can  expand 
into  an  enormous  mass  of  material  (e.g.,  the  verification  conditions  are 

many  times  the  length  of  the  program  itself).  Fortunately,  much  of  the 
volume  can  be  reduced  by  simplification  at  various  stages  of  the  proof 

process.  All  the  yeri f icat ion  conditions--although  long--are  elementary 
proo  1  s . 

The  simplicity  of  most  proofs,  together  with  the  sheer  number  to 
be  performed,  are  fundamental  reasons  why  major  research  should  be  con¬ 
tinued  in  semi-automatic  deductive  systems.  Simplification  packages 
and  interactive  programs  to  help  the  programmer  direct  the  machine  to 
a  proof  should  also  be  part  of  this  research  in  deductive  systems. 


Table  VIII- 1 


EXAMPLE  PROGRAM 


DATA  DIVISION . 

PILE  SECTION. 

PD  INPUT-MASTEh-FILE. 

01  INPUT-MASIER-RtCORD. 

02  PERMANENT-INFORMATION. 

03  NAME- In  PICTURE  X( 35) - 
03  SOCIAL- SECURITY-IN  PICTURE  9(9). 

03  WEEKLY-SALARY-IN  PICTURE.  999V99. 

02  VARYING-INFORmATION. 

03  GROSS-PAY-TU-DATE-IN  PICTURE  99999V99- 
03  HUUnG-WOHKED- TO-DATE- IN  PICTURE  9999- 
03  CJRRENT-WEEK-IN  PICTURE  99. 

02  AnHAY-INFORnATION . 

03  HOURS- WORK ED- WEEKLY -IN  PICTURE  99  OCCURS  52  TIMES. 

PD  OUTPUT-1'iASTt.n-FILE . 

01  OUTPUT-MASTC.i-RECORD . 

02  PERMANENT-INFORMATION. 

03  NAME-OUT  PICTURE  X(35). 

03  SOCIAL-SECURITY-OUT  PICTURE  9(9). 

03  WEEKLY-SALARY-OUT  PICTURE  999V99  . 

02  VAR YING-INFORMATIOH . 

03  GROSS- PAY-TO-DATE-OUT  PICTURE  99999V99- 
03  HOURS- WORKED-TO-DATE-OUT  PICTURE  9999- 
03  CURRENT-WEEK-OUT  PICTURE  99- 
02  ARnaY-INFORMATION. 

03  hoURS-WORKED-WEEKLY-OUT  PICTURE  99  OCCURS  52  TIMES. 

FD  TIME-CARD-FILE. 

01  TIME-CARD. 

02  NAME  PICTURE  X(35) • 

02  HoURS-WGRKED-THIS-WEEK  PICTURE  99- 

FD  PAYCHECK-FILE. 

01  PAYCHECK. 

02  NAME  PICTURE  X(3b). 

02  AMOUNT  PICTURE  999V99- 

WORKING-STORAGE  SuCTION. 

77  TrilS- WEEKS- PAY  PICTURE  999V99- 
77  I  PICTURE,  99- 
77  FILE-FLAG  PICTURE  9. 

PROCEDURE  DIVISION. 
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WAIN  SUCTION. 


OPEN-FILES . 

( A33EH  1’  1  )  . 

OPEN  INPUT  INPU  T-HASTEn-FlLE . 
OPEN  INPUT  T1mE-CARD-FIL£. 

OPEN  OUTPUT  OUTPUT-MASTER-FILE. 
OPEN  OUTPUT  PAYCHECK-FILE. 


LOOP. 

(A33ER1  2) 

PERFORM  READ-INPUT-MASIER  THRU  READ-TIME-CARD. 

IF  FILE-FLAG  =  2  GO  TO  CLEANUP. 

IF  FILE-FLAG  NOT  =  0  GO  TO  ERROR-ABORT. 

PERFORM  PROCESS-RECORDS. 

PERFORM  WRITE-OUTPUT. 

GO  TO  LOOP. 

READ-INPUT-MA3ft.il . 

READ  I NPU i  -MAS j  £ R- F I LE  AT  END  ADD  1  l'O  FILE-FLAG. 
READ-TIME-CARD. 

READ  TImE-CAHD-FILF  AT  END  ADD  1  TO  FILE-FLAG. 


wfll Tc-OUTPUT . 

WRITE  OU TPJ T-MAS 1 tn-RECORD . 
WRITc.  PAYCHECK . 


CLEANUP. 

( A33t,fi i  3)  • 

CLOSE  INPU  1-MASfc.R-r  ILE  . 
CLGot,  UuTPUT-MA3Tt,R-FILE. 
CLOSE  PAYCHECK-FILc. . 

STOP  RUN  ( ASSc.R i  3). 


t,  n  rfOR-  AcOR  T  . 

(  ASSi^n  1  4)  . 

SiwF  RUN  (  ASCl.im  4  '  . 

PpOCESSI.jG  SECTION. 

PRjCESS-HECORDS. 

IF  NAME-IN  NOT  =  NAME  OF  TIME-CARD  GO  TO  ERROR-ABORT. 

MOVE  NAME-IN  Tj  NAmE-OUT . 

MOVE  SOCI AL-ScCUHI TY-IN  TO  SOCIAL-SECURITY-OUT. 

MOVE  WEiiKI. Y-3ALAH Y-IN  TO  WEEKLY-SALARY-OUT. 

COMPUTE  THI3-WEEKS- PAY  ROUNDED  =  WEEKLY-SALARY-IN  » 
l HOURS-WOHKED-THI3-WE5K  /  40) 

ON  SIZE  ERROR  GO  TO  ERROR-ABORT. 

COMPUTE  GROSG-PAY-TU-DATE-OUT  =  GR0S3-PAY-T0-DATE-IN  + 
T.iiJ- WEEKS- PAY . 

COMPUTE-^  jURS-  WORK.1  D-Tj-DATE-OUT  -  HOURS- WORKED-TO-DATE-IN 

hours- work ed- this- week. 
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COilPUTE  CURRENT- WEEK-OuT  =  CURREN T-WEEK-IN  +  1. 
PERFORM  .iOVE-ARKkY  VARYING  I  FROM  1  BY  1  UNTIL  I  >  52 
(ASSEhT  7) • 

COMPUTE,  HOURS-WORKED-WEEKLY-OUT  (CURRENT-WEEK-OUT)  * 
HOURS-WORKED-THIS- WEEK. 
nOVE  CORRESPONDING  TIME-CARD  TO  PAYCHECK. 

MOVE  ThIS-WEEKS-PAY  TO  AMOUNT. 

MOVE-ARRAY. 

MOVE  HOURS- WORKED- WEEKLY- IN  (I)  TO 
HOURS-WORKED-WEEKLY-OUT  (I). 


ERROR-ABORT. 

( ASSERi  5) • 

STOP  RUN  ( ASSEitf  5). 
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Table  VIII-2 


ASSERTIONS  FOrt  SAMPLE  PROGRAM 


(1  (AND  [POHALL  X  (IMPLIES  (AND  ( LTQ  1  X) 

(LTQ  X  INPUT-MASTER-FILE. LENGTH)) 
(AND  (EQ  (SELECT  NAmE-IN .ARRAY  (X)) 
(SELECT  (QUAL  NAME. ARRAY 
TIME-CARD) 

(X))) 

(GTQ  0  (SELECT  CURRENT-WEEK-IN .ARRAY 

(X))) 

(LTQ  (SELECT  CURRENT-WEEK-IN .ARRAY 
(X)) 

51  ) 

(EQ  INPUT-rtASTEH-FILE. LENGTH  TIME-CARD-FILE . LENGTH )) ) 

(2  (AND  (ASSC.HI'  7) 

(LTQ  INPUT-MAS ftrt-FILE . INDEX  INPUT-MASTER-FILE. LENGTH) 

(EQ  FILE-FLAG  0) 

(EQ  INPUT-MAS Ith-FILE. INDEX  TIME-CARD-FILE . INDEX 

OUTPUT-MAS  TER- FILE . LENGTH  PAYCHECK-FILE . LENGTH) ) ) 

(3  (ANJ  (ASSErti  7) 

(GT  INPUT-MASTER-FILE. INDEX  INPUT-MASTER-FILE . LENGTH ) 

(GT  TIME-CARD-FILE. INDEX  TIME-CARD-FILE . LENGTH) 

(EQ  FILE-FLAG  2) 

(EQ  INPUT-MASIER-FILE. LENGTH  OU TPUT-MASIER-FILE . LENGTH 
PAYCHECK-FILE . LENGTH ) ) ) 

(4  FALSE) 

L  5  (EXISTS  X  (AND  ( EQ  X  INPUT-mASTER-FILE. INDEX) 

(OH  (GT  (TIMES  (SELECT  WEEKLY-SALARY-IN  .ARRAY 

(X)) 

( DIVIDE  (SELECT 

HOURS-WORKED-THIS-WEEK . ARRAY 
(X)) 

40)) 


[6 


(AND  ( ASSERT  7) 


999 -999) 

( NEQ  (SELECT  NAME-IN . ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 
(X] 


(EQ  (SUBTRACT  INP J T-MASI tR-FILE . LENGTH  1) 

(SUBTRACT  TIME-CARD-FILE. INDF\  1) 
OUTPUT-HASTER-FILE .  LENGTH  PAY  CHECK-FILE.  LENGTH) 
(EQ  NAME-IN  (QUAL  NAME  TIME-CARD) 

NAME-uUT 


(QUAL  NAME  PAYCHECK)) 

L EQ  GR0S3-PAY-T0-DATE-0UT 

(PLUS  GROSS- PA Y-TO-DAI E- IN 

(ROUND  999V99  (TIMES  WEEKLY-SALARY- IN 

(DI7IDE  HOURS-WORKED-THIS-WEEK 
40) 

(EQ  HOURS- WOH KED- TO- DAT E-OUT  (PLUS  HOURS- WORKED- TO-DATE-IN 
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HOURS- WORKED- THIS- WEEK) ) 
(EQ  CURHEWT-WEEK-OUT  (PLUS  1  CURRENT-WEEK-IN ) ) 

( LTQ  1  I) 

(FOR ALL  Y  (IMPLIES  (AND  (LTQ  1  Y) 

(LTQ  Y  (SUBTRACT  I  1))) 

(EQ  (SELECT  HOURS-WORKED- WEEKLY-OUT 

( Y) ) 

(SELECT  HOU RS- WORKED- WEEKLY-IN 

m 

L  7 

(AND 

(ASSERT  1) 

(FORALL 


X 

(IMPLIES 

(AND  (GTQ  1  X) 

(LTQ  X  OUTPUT-MASTEH-FILE .  INDEX) ) 

(AND  (EQ  (SELECT  NAME-IN .ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 

(X)) 

(SELECT  NAME-OUT. ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  PAYCHECK) 

(X))) 

[EQ  (SELECT  GROSS- PAY-TO-DATE-OUT .ARRAY  (X)) 

(PLUS  (SELECT  GROSS- PA Y-TO-DATE-IN . ARRAY  (X)) 
(ROUND  999 V99  (TIMES  (SELECT 

WEEKLY-SALARY-IN .ARRAY 
(X)) 

(DIVIDE  (SELECT 
HOU RS-WORKED-THIS-WEEK. ARRAY 

(X)) 

401 

[EQ  (SELECT  HOURS-WORKED- TO-DATE-OUT .ARRAY  (X)) 

(PLUS  (SELECT  HOURS-WORKED- TO-DATE-IN  .ARRAY 
(X)) 

(SELECT  HOURS- WORKED- THIS- WEEK .ARRAY  (X] 
[EQ  (SELECT  CURRENT-WEEK-OUT .ARRAY  (X)) 

(PLUS  1  (SELECT  CURRENT-WEEK-IN . ARRAY  (X] 

[FORALL  Y  (IMPLIES  (AND  (LTQ  1  Y) 

(LTQ  Y  52) 

(NEQ  Y  (SELECT 

CURRENT-WEEK-OUT .ARRAY 
(X] 

(EQ  (SELECT  (SELECT 

HOURS- WORKED- WEEKLY-OUT. ARRAY 
(X)) 

(Y)) 

(SELECT  (SELECT 
HOURS-WORKED-WEEKLY-IN .ARRAY 
(X)) 

(Y3 

(EQ  (SELECT  (SELECT  HOURS-WORKED- WEEKLY-OUT . ARRAY 

(X)) 
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(SELECT  CURRENT- WEEK-OUT. ARRAY  (X))) 
(SELECT  HOURS- WORKED-MIS-WEEK.  ARRAY  (X] 
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Table  VIII-3 


TRANSDUCED  EXAMPLE  PROGRAM  (PROCEDURE  DIVISION) 


( PROCEDUREDIVISION$ 

[SECTION*  MAIN  ( PARAGRAPH*  OPEN-FILES  (ASSERT  1) 

(OPENINPUT*  INPUT-MASTER-FILE) 

(OPENINPUT*  T IME-CARD-FILE) 

(OPENOUTPUT*  OUTPUT-MASTER-FILE) 
(OPENOUTPUT*  PAYCHECK-FILE)) 

(PARAGRAPH*  LOOP  ( ASSORT  2) 

(PERFORM  (ONCE*) 

(DO*  READ-INPUT-MASTER  RE AD-TIME- CARD) 
NIL  NIL) 

(IF  (EQ  FILE-FLAG  2) 

(GO  CLEANUP) 

(NEXT)) 

(IF  (NEO  FILE-FLAG  0) 

(GO  ERROR-ABORT) 

(NEXT)) 

(PERFORM  (ONCE*) 

(DO*  PROCESS-RECORDS  PROCESS-RECORDS) 
NIL  NIL) 

(PERFORM  (ONCE*) 

(DO*  WRITE-OUTPUT  WRITE-OUTPUT) 

NIL  NIL) 

(GO  LOOP)) 

(PARAGRAPH*  RLAD-INPUT-MA3TCK 

(READ  INPUT-MASTER-FILE  NIL 

(SET*  FILE-FLAG  (PLUS  FILE-FLAG  1) 

NIL))) 

(PAHAGRAPH*  READ-TIME-CARD  (READ  TIME-CARD-FILE  NIL 


(SET*  FILE- FLAG 

(PLUS  FILE-FLAG  1) 
NIL))) 

(PARAGRAPH*  WRITE-OUTPUT  (WRITE  OUTPUT-MASTER-RECORD  NIL) 
(WRITE  PAYCHECK  NIL)) 

(PARAGRAPH*  CLEANUP  (ASSERT  3) 

(CLOSE  IN PUT-MASTER- FILE) 


(CLOSE  TIME-CARD-FILE) 


( CLOSE  OUTPUT-MASTER-FILE) 
(CLOSE  PAYCHECK-FILE) 

(STOP  (ASSERT  3))) 
(PARAGRAPH*  ERROR-ABORT  (ASSERT  4) 
(STOP  (ASSERT  4] 

(SECTION*  PROCESSING  (PARAGRAPH*  PROCESS-RECORDS 


(IF  ( NEQ  NAME-IN  (QUAL  NAME 

TIME-CARD)) 


(GO  ERROR-ABORT) 

(NEXT)) 

(SET*  NAME-OUT  NAME- IN  NIL) 
(SET*  SOCIAL- SECURITY-OUT 
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SOCIAL-SECURITY-IN  NIL) 

( SET*  WEEKLY-SALARY-OUT 

WEEKLY-SALARY-IN  NIL) 
(SETROUNDED$  THIS-WEEKS-PAY 

(TIMES  WEEKLY-SALARY-IN 
(DIVIDE 

HOURS- WORK ED- THIS- WEEK  40)) 
(GO  ERROR-ABORT)) 

(SET$  GROSS-PAY-TO-DATE-OUT 

(PLUS  GROSS-PAY- TO-DATE-IN 
THIS-WEEKS-PAY) 

NIL) 

(SET$  HOURS-WORKED-TO-DATE-OUT 

(PLUS  HOURS- WORKED -TO-DATE- IN 
HOURS-WORKED-THIS-WEEK) 

NIL) 

( SET*  CURRENT- WEEK-OUT 

(PLUS  1  CURRENT-WEEK-IN) 

NIL) 

(PERFORM  VARYING  (DO*  MOVE- ARRAY 

MOVE-ARRAY) 

(I  1  1  (GT  I  52)) 

(ASSERT  6)) 

(SET*  (SELECT 

HOURS-WORKED-WEEKLY-OUT 
(CURRENT-WEEK)) 
HOURS-WORKED-THIS-WEEK  NIL) 
(MOVECORRES PONDING*  TIME-CARD 

PAYCHECK) 

( set$  amount  this-weeks-pay  nil)) 

( PARAGRAPH*  MOVE-ARRAY  (SET*  (SELECT 

HOURS-WORKED-WEEKLY-OUT 

(I)) 

(SELECT  HOURS- WORK ED- WEEKLY- IN 
(I)) 

NIL)) 

( PARAGRAPH*  ERROR-ABORT  (ASSERT  5) 

(STOP  (ASSERT  51) 
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Table  VIII-4 


TRANSDUCED  EXAnPLE  PROGRAM  (DATA  DIVISION) 


(datadivision$ 
(f ILESECTIOH$ 


[FD  INPUT-rtASTER-FILE  ({(1  INPUT-MASTER-RECORD) 
(((2  PERMANENT-INFORMATION) 

((3  NAME-IN  X*( 35J ) ) 

(3  SOCIAL-SECURITY-IN  9f(9J)) 

(3  WEEKLY-SALARY-IN  999V99))) 

((2  VAR YING- IN FORMAT ION ) 

((3  GR03S-PAY-T0-DATE-IN  99999 V99) 

(3  H0UR5-W0RKED-T0-DATE-1N  9999) 

(3  CURRENT-WEEK-IN  99))) 

((2  ARRAY-INFORMATION) 

((3  HOURS- WORKED- WEEKLY-IN  99  52] 

[FD  OuTPU r-i'lAS rt.r(-FILE  (((1  OUTPUT-MASTER-RECORD) 
(((2  PERMANENT-INFORMATION) 

((3  NAME-OUT  Xt(35$)) 

(3  SOCIAL- SECURITY-OUT  9*(9I)) 

(3  WEEKLY-SALARY-OUT  999V99))) 

((2  VARYING-INFORhATION) 

((3  GRUSS-PAY-TO-DATE-OUT  99999 V99) 

(3  hjURS-WORKED-TO-DATE  9999) 

(3  CURRENT-WEEK-OUT  99))) 

((2  «RHttY-INFORMATION) 

((3  HOURS-WORKED-WEEKLY-OJT  ^9  52] 

[FD  TIME-CArtD-FILE  (((1  TIME-CARD) 

((2  NAME  X*(35*)) 

(2  HOURS- WORKED- THIS- WEEK  .9] 


(FD  PAYCHECK-FILE  (((1  PAYCHECK) 

((2  NAME  XX35J ) ) 

(2  AMOUNT  999V99J 

(  WORKINGSrORAGESEC TION$  (77  THIS- WEEKS- PAY  999 V99) 

(77  I  999) 

(77  FILE-FLAG  9))) 


125 


TabLe  VIII-5 


EXAMPLE  PROGRAM  AFTER  POSTTRANSDUCTION  PROCESSING 
AND  SIMPLIFICATION 


( ( ASSihT  1) 

(ASSIGN  INPUT-MASTER-FILE. INDEX  0) 

(ASSIGN  TIi iE-CAHD- FILE . INDEX  0) 

(ASSIGN  OUTPUT-MASTEn-FILE. INDEX  0) 

(ASSIGN  PAYChECK-FILE. INDEX  0) 

(ASSORT  2) 

[BLOCK  (ASSIGN  INPUT-MASIER-FILE . INDEX  (PLUS  INPUT-MASTER-FILE . INDEX 

D) 

(IF  (GT  INPUT-nASTER-FILE. INDEX  INPUT-MASTER-FILE . LENGTH ) 
(ASSIGN  FILE-FLAG  (PLUS  FILE-FLAG  1)) 

(NEXT)) 

( ASSIGN  NAME-IN  (SELECT  NAmE-IN  .ARRAY  ( INPUT-MASTER-FILE .  INDEX) 

)) 


( ASSIGN 


( ASSIGN 
( ASSIGN 


( ASSIGN 


SOCIAL-SlCURITY-IN  (SELECT  SOCIAL- SECURITY- IN .ARRAY 

( IN PUT- MASTER-FILE . INDEX) ) ) 
WEEKLY -SALARY- IN  (SELECT  WEEKLY-SALARY-IN . ARRAY 

(INPJT-rtASTER-FILE. INDEX)  )  ) 
GROSS-PAY-TO-DATE-IN  (SELECT 

GROSS-PAY-TO-DATE-IN .ARRAY 

( IN PUT-MASTER- FILE . INDEX) ) 

) 

HOU RS- WORK ED- TO- DATE- IN  (SELECT 

HOURS- WORKED-TO-DATE-IN. ARRAY 


( 


INPUT-MASFEii-FILE  .  INDEX) ) ) 

(ASSIGN  CURR&NT-WEEK-IN  (SELECT  CURRENT-WEEK-IN . ARRAY 

( INPUT-MASTER-FILE . INDEX) )  ) 
(ASSIGN  HOURS-WOnK ED- WEEKLY- IN  (SELECT 

HOURS- WORKED- WEEKLY-IN .ARRAY 

( INPU  I-rtA3 TER- FILE  .  INDEX 

))) 

(ASSIGN  TIME-CARD-FILE. INDEX  (PLUS  TImE-CARD-FILE . INDEX  1)) 

(IF  (GT  TIME-CARD-FILE . INDEX  TIME-CARD-FILE . LENGTH) 

(ASoIGN  FILE-FLAG  (PLUS  FILE-FLAG  1)) 

(NEXT) ) 

(ASSIGN  (QUAL  NAME  TImE-CARD) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 

( TIME-CARD-FILE. INDEX) ) ) 

(ASSIGN  HOU  RS- WORKED -THIS- WEEK 


(SELECT  rlUURS-WORKED-TrilS-WEEK.  ARRAY  ( 
TIME-CARD-FILE . INDEX] 


(If  ( EQ  FILE- FLAG  2) 

(GO  (CLEANUP  mA IN ) ) 
(NEXT)) 

(IF  ( NEC  FILE-FLAG  0) 

'GO  (Frt.iOR-AirORT  MAIN)) 


(NeXT)) 
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(BLOCK  (IF  (NEQ  NAmE- IN  (QUAL  NAriE  TIME-CARD)) 

(GO  ( ERROR- ABORT  PRQCE3GUG)) 

(NEXT)) 

(ASSIGN  NAnE-OUT  NAME- IN ) 

( ASSIGN  SOCIAL-SECURITT-ODT  SOCIAL- SECURITY- IN) 

( ASSIGN  WEEKLY- SAL ARY-OUT  WEEKLY-SALARY-IN) 

[IF  (GT  [ ABS  ( ROUND  THIS- WEEKS- PAY  (TIMES  WEEKLY-SALARY-IN 

(DIVIDE 

HOURS- WORKED- THIS- WEEK  40] 

999  -99) 

(GO  (ERROR-ABORT  PROCESSING)) 

(ASSIGN  rrilS-WEtKS- PAY  (ROUND  TrilS- WEEKS- PAY 

(TIMES  WEEKLY-SALARY-IN 
(DIVIDE 

HOURS- WORKED- THIS- WEEK  40 J 

(ASSIGN  SROSS-PAY-TO-DATE-OUT  (PLUS  GROSS-PAY-TO-DATS-IN 

THIS-WEEKS-PAY) ) 

(ASSIGN  HOURS- WORKED-TO-D AT c,-OUT  (PLUS  HOURS-WORKED- TO-DATE-IN 

HOURS- WORKED- THIS-WEEK) ) 

( ASSIGN  CURREN i- WEEK -GUT  (  PLoS  1  CURRENT-WEEK-IN) ) 

[BLOCK  (ASSIGN  I  1) 

(ASSEHi  6) 

(IF  (GT  I  52) 

( ENDPEHFORM) 

(NEXT)) 

(ASSIGN  (SELECT  HoURS-WORKED-WEEKLY-OUT  (I)) 

(SELECT  .ioURS- WORKED- WEEKLY- IN  (I))) 

(ASSIGN  I  (PLUS  I  1)) 

(LOOPASoc.ni  (ASSaiw'  6] 

(ASSIGN  (SELECT  rioURS-WORKED-WEEKLY-OUT  ( CJRREN T-WEEK) ) 

HOURS- WORKED- ISIS- WEEK) 

(ASSIGN  (QUAL  NAME  PAYChECK) 

(QuAL  NAnE  TlnE-CARD) ) 

(ASSIGN  AMOUNT  THIS-WEEKS-PAY) ) 

(BLOCK  (ASSIGN  OUT  PUT-MAST  c.r -FILE  .  INDEX  (PLUS 

OJTPUT-M ASTER- FILE .INDEX  1 ) ) 

( assign  ouIput-masilr-file. length  (plus 

OU  rPUT-.-iASTER-FILE  .LFDGTH  i) ) 

(ASSIGN  (SELECT  A  AML-OUT . ARRAY  ( OUTPUT-MAS IER-FILE . INDEX) ) 
NAmE-OUT) 

(ASoIGN  (SELECT  SOCIAL- SECURITY-OUT . ARnAY  ( 

OUTPUT-MASTlR-FILE  .  INDEX)  ) 

SOCIAL- SECURITY -OUT) 

(ASSIGN  (SELECT  WEEKLY-SALARY-OuT .ARRAY  ( 

OUT PUT- MAS  TER- FILE . INDEX) ) 

WEEKLY-SALARY-OUT) 

(ASSIGN  (SELECT  GROSS-PA Y-TO-DATE-OUI .ARRAY  ( 

OUTPUT-. lAoibR-FILE. INDEX) ) 
oROSS-PAY-TO-DATE-OUT) 

(ASSIGN  (SELECT  HOUHo-WOHKED- TO-DATE-OUT .ARRAY  ( 

OU T PUT- t'lASl  ER- FILE  .  INDEX)  ) 

HOURS- WORKED- TO-DATE- OUT) 

(ASSIGN  ( SELECT  CURRENT- WEEK-OUT. ARRAY  ( 
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OUTPuT-nASTcH-FILE. INDEX) ) 

CURRsN  I-wEEK-OUT ) 

(ASSIGN  (SELECT  duURS-WORKKD-WEEKLY-OU  i'  .ARRAY  ( 
GUTPUT-MASTtR-FILE  .  INDEX) ) 

Hod  RS-  WOR  K  ED-  WEEKL  Y-OUT ) 

(ASSIGN  PAYCHECK-FILE .  INDEX  (PLUS  PAYCHECK-FILE  .  INDEX  1)) 
(ASSIGN  PAYCHECK-FILE . LENGTH  (PLUS  PAYCHECK-FILE . LENGTH  1)) 
(ASSIGN  (SELECT  (QUAL  NAME. ARRAY  PAYCHECK) 

(PAYCHECK-FILE. INDEX)) 

(Q UAL  NAME  PAYCHECK)) 

(ASSIGN  (SELECT  AMOUNT. ARRAY  ( PA YCHECK-FILE . INDEX) ) 

AMOUNT) ) 

(LjoF  SAIN)) 
oi.IT  }) 

v'P  (ASSi^n.  3).' 

Sc.R  R ) 

jp  (  ASSCn i’  *1  ) )  ) 
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Table  VIII-6 


SIGNIFICANT  PATHS  FOR  THE  EXAMPLE  PROGRAM 


((ASSERT  2) 

(ASSIGN  PAYCHECK-FILE. INDEX  0) 

(ASSIGN  OUTPUT-MASTER-FILE. INDEX  0) 

(ASSIGN  TIME-CARD-FILE. INDEX  0) 

(ASSIGN  INPUT-MASTER-FILE. INDEX  0) 

(ASSERT  1)) 

((ASSERT  3) 

(IF  (EQ  FILE-FLAG  2) ) 

(ASSIGN  HOURS-WORKED-THIS-WEEK  (SELECT  HOURS- WORKED-THIS-WERK . ARRAY 

( TIME-CARD-FILE . INDEX) ) ) 

(ASSIGN  (QUAL  NAME  TIME-CARD) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 

( TIME-CARD-FILE . INDEX) ) ) 

(ASSIGN  FILE-FLAG  (PLUS  FILE-FLAG  1)) 

(IF  (GT  TIi'E-CARD-FILE .  INDEX  TIME-CARD-FILE  .LENGTH) ) 

(ASSIGN  TIME-CARD-FILE. INDEX  (PLUS  TIME-CARD-FILE . INDEX  1)) 

(ASSIGN  HOU RS- WORKED- WEE KLY-IN  (SELECT  HOURS- WORKED-WEEKLY-IN .ARRAY 

( INPUT-MASTER-FILE . INDEX) ) ) 

(ASSIGN  CURRENT- WEEK-IN  (SELECT  CURRENT-WEEK-IN .ARRAY  ( 

INPUT-: V  5TER- FILE .  INDEX) ) ) 

(ASSIGN  HOURS-WORKED-TO-DATE-IN  (SELECT 

HOURS- WORKED-TO-DATE-IN. ARRAY 

( INPUT-MASTER-FILE . INDEX ) ) ) 

(ASSIGN  GROSS-PAY-TO-DATE-IN  (SELECT  GROSS-PAY-TO-DATE- IN .ARRAY 

( INPUT-MASTER-FILE . INDEX) ) ) 

(ASSIGN  WEEKLY-SAL ARY- IN  (SELECT  WEEKLY-SALAR Y-IN . ARRAY  ( 

INPUT-MASTER-FILE. INDEX) ) ) 

(ASSIGN  SOCIAL-SECURITY-IN  (SELECT  SOCIAL-SECURITY-IN .ARRAY 

( INPUT-MASTER-FILE . INDEX) ) ) 

(ASSIGN  NAME-IN  (SELECT  NAME-IN . ARRAY  ( INPUT-MASTER-FILE. INDEX) ) ) 
(ASSIGN  FILE-FLAG  (PLUS  FILE- FLAl.  O) 

(IF  (GT  INPUT-MASTER-FILE. INDEX  INPUT-MASTER-FILE .LENGTH) ) 

(ASSIGN  INPUT-MASTER-FILE. INDEX  (PLUS  INPUT-MASTER-FILE . INDEX  1)) 

( ASSERT  2) ) 

( (ASSERT  5) 

(IF  (GT  [ASS  (ROUND  THIS- WEEKS- PAY  (TIMES  WEEKLY-SALARY-IN 

(DIVIDE 

HOURS-WORKED-THIS-WEEK  40] 

999-99)) 

(ASSIGN  WEEKLY-SALARY-OUT  WEEKLY-SALARY-IN) 

(ASSIGN  SOCIAL-SECURITY-OUT  SOCIAL-SECURITY-IN) 

(ASSIGN  NAME-OUT  NAME- IN) 

[IF  (NOT  ( NEQ  NAME-IN  (QUAL  NAME  TIME-CARD] 

(IF  (NOT  (NEQ  FILE-FLAG  0))) 

(IF  (NOT  (EQ  FILE-FLAG  2))) 

(ASSIGN  HOURS-WORKED-THIS-WEEK  (SELECT  HOURS- WORKED- THIS- WEEK. ARRAY 

(TIME-CARD-FILE . INDEX) ) ) 

(ASSIGN  (QUAL  NAME  TIME-CARD) 
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(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 


(TIME-CARD-FILE. INDEX) ) ) 

(IF  (NOT  (GT  TIME-CARD-FILE . INDEX  TIME-CARD-FILE . LENGTH) ) ) 

(ASSIGN  TIME-CARD-FILE. INDEX  (PLUS  TIME-CARD-FILE . INDEX  1)) 

(ASSIGN  HOU  RS- WORKED- WEEKLY-IN  (SELECT  .HOURS- WORKED-WEEKLY-IN  .ARRAY 

( INPUT-MASTER-FILE . INDEX) ) ) 

(ASSIGN  C'JRRENT-WEEK-IN  (SELECT  CURRENT-WEEK-IN .  ARRAY  ( 

INPUT- MASTER- FILE . INDEX ) ) ) 

(ASSIGN  HOURS- WORK ED -TO- DATE- IN  (SELECT 

HOURS- WORKED-TO-DATE-IN. ARRAY 

( INPUT-MASTER-FILE . INDEX) ) ) 

(ASSIGN  GROSS- PAY-TO-DATE-IN  (SELECT  GROSS-PAY- TO-DATE-IN .ARRAY 

( INPUT-MASTER-FILE . INDEX) ) ) 

(ASSIGN  wEEKLY-SALARY-IN  (SELECT  WEEKLY-SALARY-IN . ARRAY  ( 

INPUT-MASTER-FILE . INDEX) ) ) 

(ASSIGN  SOCIAL- SECURITY-IN  (SELECT  SOCI AL-SECURITY-IN . ARRAY 

( INPUT-MASTER-FILE . INDEX) ) ) 

(ASSIGN  NAME- IN  (SELECT  NAME-IN .ARRAY  ( INPUT-MASTER-FILE . INDEX) ) ) 
(IF  (NOT  (GT  1NPUT-MA5TF.H-FILE  .  INDEX  INPUT-MASTER-FILE  .  LENGTH) )  ) 
(ASSIGN  INPUT-MASTC.R-FILE.  INDEX  (PLUS  INPUT-MASTER-FILE .  INDEX  1)) 

(ASSERT  SI' 

((ASSERT  b; 


(ASSIGN 
( ASSIGN 
( ASSIGN 


( ASSIGN 
( ASSIGN 


( IF  (NO 


I  1) 

CURRENT- WEEK-OUT  (PLUS  1  CURRENT-WEEK-IN ) ) 

HOUR3-WORKED-TO-D ATE-OUT  (PLUS  HOURS -WORK ED- TO- DATE- IN 

HOURS- WORK ED- THIS- WEEK) ) 

GROSS- PAY-TO-DATL-OUT  (PLUS  GROSS- PAY-TO-DATE-IN 

THIS-WEEKS-PAY) ) 

THIS-WEEKS-PAY  (ROUND  THIS-WEEKS-PAY 

(TIMES  WEEKLY-SALARY-IN 

(DIVIDE  HOURS- WORKED- THIS- WEEK 
40] 

I  (GT  [ABS  (ROUND  THIS-WEEKS-PAY  (TIMES  WEEKLY-SALARY-IN 

(DIVIDE 

HOURS- WORK ED- THIS- WEEK  40] 


999.99)) ) 


'  «SS:  rtiSEKLY -SALARY-JUT  WEEKLY-SALARY-IN) 

( A S S I G M  S 0 C I  A L- S EC U R 1 1 Y - 0 J T  SOCIAL-SECURITY-IN) 
(ASSIGN  NAME-OUT  NAME-IN) 

l  IF  v  NOT  (NEO  NAME-IN  ( QUAL  NAME  TIME-CARD] 

(IF  (NOT  ( NEQ  FILE- FLAG  0))) 

(  IF  (NOT  (EQ  :•  ILE-FLAG  2)  )  ) 


(ASSIGN  HOjU  RS-  WORK  ED-THI S-  WEEK  (SELECT  HOURS-WORKED-THIS- WEEK .  ARRAY 

(TIME-CARD-FILE. INDEX) ) ) 

(ASSIGN  (QUAL  NAME  TIME-CARD) 

(SELECT  t,  QUAL  NAME. ARRAY  TIME-CARD) 

(TIME-CARD-FILE. INDEX) ) ) 

(IF  'No!  (GT  TIME-CARD-FILE.  INDEX  TIME-CARD-FILE  .LENGTH) ) ) 

(ASjIGN  TIME-CARD-FILE. INDEX  ( PLUS  TIME-CARD-FILE . INDEX  1)) 

(ASSIGN  HOURS- WORKED-WEEKLY-IN  (SELECT  HOURS-WORKED-WEEKLY-IN . ARRAY 

( INPUT-MASTER-FILE. INDEX))) 

(h  .’ION  CURRENT-  WEEK-IN  (SELECT  CURRENT- WEEK-IN  .  ARRAY  ( 

INPUT-MASTER-FILE. INDEX) ) ) 
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( ASSIGN  HOURS- WORKED -TO- DATE- IN  (SELECT 

HOURS-WORKED-TO-D4TE-IN. ARRAY 

( INPUT-MASTER-FILE . INDEX) ) ) 

( ASSIGN  GROSS- PAY- TO-DATE- IN  (SELECT  GROSS- PAY-TO- DATE-IN .ARRAY 

( IN PUT-MASTER -FILE . INDEX ) ) ) 

(ASSIGN  WEEKLY -SAL ARY- IN  (SELECT  WEEKLY-SALARY-IN .ARRAY  ( 

INPJT-MA3TBR-FILE . INDEX) ) ) 

(ASSIGN  SOCIAL-SECURITY-IN  (SELECT  SOCIAL- SECURITY-IN .ARRAY 

( INPUT-MASTER-FILE . INDEX ) ) ) 

(ASSIGN  NAME-IN  (SELECT  NAME-IN .ARRAY  ( INPUT-MASTER-FILE. INDEX) ) ) 

(IF  (NOT  (GT  INPUT-MASTER-FILE . INDEX  INPUT-MASTER-FILE . LENGTH) ) ) 
(ASSIGN  INPUT-MASTER-FILE. INDEX  (PLUS  INPUT-MASTER-FILE . INDEX  1)) 
(ASSERT  2) ) 

((ASSERT  5) 

(ASSIGN  I  (PLUS  ID) 

(ASSIGN  (SELECT  HOURS-WORKED-WEEKLY-OUT  (I)) 

(SELECT  HOURS- WORKED- WEEKLY- IN  (I))) 

(IF  (NOT  (GT  I  52))) 

(ASSERT  6)) 

((ASSERT  2) 

(ASSIGN  (SELECT  MOUNT . ARRAY  ( PAYCHECK-FILE . INDEX) ) 

(QUAL  AMOUNT  PAYCHECK)) 

(ASSIGN  (SELECT  (QUAL  NAME. ARRAY  PAYCHECK) 

(PAYCHECK-FILE. INDEX) ) 

(QUAL  NAME  PAYCHECK)) 

(ASSIGN  PAYCHECK-FILE. LENGTH  (PLUS  PAYCHECK-FILE .LENGTH  D) 

(ASSIGN  PAYCHECK-FILE. INDEX  (PLUS  PAYCHECK-FILE . INDEX  D) 

(ASSIGN  (SELECT  HOURS-WORKED-WEEKLY-OUT . ARRAY  ( 

OUTPUT-MAS  TER- FILE . INDEX ) ) 

HOURS-WORKED-WEEKLY-OUT) 

(ASSIGN  (SELECT  CURRENT-WEEK-OUT .ARRAY  ( OUTPUT-MASTER-FILE . INDEX ) ) 
CURRENT-'WEEK-OUT) 

(ASSIGN  ( SELECT  HOURS-WORKED-TO-DATE-OUT . ARRAY  ( 

OUTPUT-MASTEh-FILE . INDEX) ) 

HOURS-WORKED-TO-DATE-OUT) 

(ASSIGN  (SELECT  GROSS- PAY-T3-DATS-0UT .ARRAY  ( 

OUTPUT-MASTER-FILE . INDEX) ) 

GROSS- PAY-TO-D ATE-OUT) 

(ASSIGN  (SELECT  WEEKLY-SALARY-OUT .ARRAY  ( OUT PUT- (5ASTER- FILE . INDEX) ) 
WEEKLY-SALARY-OUT) 

(ASSIGN  (SELECT  SOCIAL-SECURITY-OUT .ARRAY  ( OUTPUT-MASTER-FILE . INDEX) ) 
SOCIAL-SECURITY-OUT) 

(ASSIGN  (SELECT  NAME-OUT . ARRAY  ( OUT PUT- MAS TER -FILE .INDEX ) ) 

NAME-OUT) 

(ASSIGN  OUTPUT -MAS I ER-FILE . LENGTH  (PLUS  OUTPUT-MASTER-FILE . LENGTH  1)) 
(ASSIGN  OUT PUT- MAS  TER- FILE . INDEX  (PLUS  OUTPUT-MASTER-FILE . INDEX  1)) 
(ASSIGN  AMOUNT  TUIS-WEEKS- PAY) 

(ASSIGN  (QUAL  NAME  PAYCHECK) 

(QUAL  NAME  TIME-CARD)) 

(ASSIGN  (SELECT  HOURS-WORKED-WEEKLY-OUT  ( CURRENT- WEEK ) ) 

HOURS- WORK ED -THIS- WEEK) 

(IF  (GT  I  52)) 

(ASSERT  6)) 
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Table  VIII-7 


VERIFICATION  CONDITION  FOR  PATH  (6-6)  OF  EXAMPLE  PROGRAM 


(IMPLIES 

[AND 

[FORALL  X  (IMPLIES  (AND  ( LTQ  1  X) 

( LTQ  X  INPUT-MASTER-FILE. LENGTH)) 

(AND  (EO  (SELECT  NAME-IN .ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 

(X))) 

(LTQ  0  (SELECT  CURRENT-WEEK-IN .ARRAY 

(X))) 

(LTQ  (SELECT  CURRENT-WEEK-IN . ARRAY 
(X)) 
bl  ] 

(  EQ  INPUT-MASTER-FILE. LENGTH  TIME-CARD- FILE . LENGTH ) 

[FORALL 

X 

( IMPLIES 

(ANP  , LT Q  1  X) 

LTQ  OUTPUT- MASTER-FILE.  INDEX) ) 

(ANl>  i  EQ  !  SELECT  NAME- IN  .ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 

(X)) 

'SELECT  NAME-OUT. ARRAY  (X)) 
l SELECT  (QUAL  NAME. ARRAY  PAYCHECK) 

(X))) 

[EQ  (SELECT  GROSS- PA Y-TO-DATE-OUT . ARRAY  (X)) 

(PLUS  (SELECT  GROSS-PAY-TO-DATE-IN . ARRAY  (X)) 
(ROUND  9H9V99  (TIMES  (SELECT 

WEEKLY-SALARY-IN .ARRAY 
(X)) 

(DIVIDE  (SELECT 
HOURS- WORKED-THIS- WEEK . ARRAY 

(X)) 

HO] 

[ KQ  (SELECT  HOURS- WORKED-TO-DATE-OUT . ARRAY  (X)) 

(PLUS  (SELECT  HOURS- WORKED-TO-DATE-IN . ARRAY  (X)) 
(SELECT  HOURS- WORKED-THIS- WEEK. ARRAY  (X] 

[Eg  (SELECT  CURRENT-WEEK-OUT. ARRAY  (X)) 

(PLUS  1  ( SELECT  CURRENT-WEEK-IN . ARRAY  (X] 

[FORALL  Y  'IMPLIES  [AND  ( GTQ  1  Y) 

(LTQ  Y  52) 

( NEQ  Y  (SELECT 

CURRENT-WEEK-OUT . ARRAY 
(X] 

(EQ  (SELECT  (SELECT 

HOURS-WORKED-WEEKLY-OUT .ARRAY 
(X)) 

(Y)) 

(SELECT  (SELECT 
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HOURS- WORKED-WEEKLY-IN .ARRAY 
(X)) 

(Y] 

(EQ  (SELECT  (SELECT  HOURS-WORKED- WEEKLY-OUT. ARRAY 

(X)) 

(SELECT  CURRENT-WEEK-OUT. ARRAY  (X))) 

(SELECT  HOURS-WOFKED-THIS- WEEK. ARRAY  (X] 

(EQ  (SUBTRACT  INPUT-MASTER-FILE. LENGTH  1) 

(SUBTRACT  TIME-CARD-FILE. INDEX  1) 

OUTPUT-MASTER-FILE . LENGTH  PAYCHECK-FILE. LENGTH) 

(EQ  NAME-IN  (QUAL  NAME  TIME-CARD) 

NAME-OUT 

(QUAL  NAME  PAYCHECK) ) 

[EQ  GROSS-PAY-TO-DATE-OUT  (PLUS  GROSS- PAY-TO-DATE-IN 

(ROUND  999V99 

(TIMES  WEEKLY-SALARY-IN 
(DIVIDE 

HOURS- WORKED-THIS- WEEK  40] 

(EQ  k'JRS- WORKED -TO- DATE-OUT  (PLUS  HOURS- WORKED- TO- DATE- IN 

HOURS-WORKED-THIS-WEEK) ) 

(EQ  CURRENT-WEEK-OUT  (PLUS  1  CURRENT- WEEK-IN) ) 

(LTQ  1  I) 

(FORALL  Y  (IMPLIES  (AND  (LTQ  1  Y) 

(LTQ  Y  (SUBTRACT  I  1))) 

(EQ  (SELECT  HOURS-WORKED- WEEKLY-OUT  (Y)) 

(SELECT  HOURS- WORKED- WEEKLY- IN  (Y] 

[IMPLIES 

(NOT  (GT  I  52)) 

(AND 

[FORALL  X  (IMPLIES  (AND  (LTQ  1  X) 

(LTQ  X  INPUT-MASTER-FILE. LENGTH)) 

(AND  (EQ  (SELECT  NAME-IN . ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 
(X))) 

(LTQ  0  (SELECT  CURRENT-WEEK-IN .ARRAY 
(X))) 

(LTQ  (SELECT  CURRENT-WEEK-IN . ARRAY 
(X)) 

51  ] 

(EQ  INPUT-MASTER-FILE. LENGTH  TIME-CARD-FILE .LENGTH) 

[FORALL 

X 

(IMPLIES 

(AND  (LTQ  1  X) 

(LTQ  X  OUTPUT-MASTER-FILE . INDEX) ) 

(AND  (EQ  (SELECT  NAME-IN . ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 

(X)) 

(SELECT  NAME-OUT. ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  PAYCHECK) 

(X))) 

[EQ  (SELECT  GROSS-PAY-TO-DATE-OUT .ARRAY  (X)) 

(PLUS  (SELECT  GROSS-PAY-TO-DATE-IH . ARRAY  (X)) 
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(ROUND  999 vgg  (TIMES  (SELECT 

WEEKLY-SALARY-IN. ARRAY 
(X)) 

(DIVIDE  (SELECT 
HOURS-WORKED-THIS- WEEK. ARRAY 

(X)) 

40] 

[EQ  ( SELECT  HOURS-WORKED-TO-DATE-OUT .ARRAY  (X)) 

(PLUS  (SELECT  HOURS- WORKED-TO-D ATE- IN . ARRAY 
(X)) 

(SELECT  HOURS- WORKED- THIS- WEEK .ARRAY  (X] 

[EQ  ( SELECT  CURRENT-WEEK-OUT .ARRAY  (X)) 

(PLUS  1  (SELECT  CUR RENT- WEEK -IN .ARRAY  (X] 

[FORALL  Y  (IMPLIES  [AND  ( GTQ  1  Y) 

( LTQ  Y  52) 

( NEQ  Y  (SELECT 

CURRENT-WESK-OUT .ARRAY 
(X] 

(EQ  (SELECT  (SELECT 

HOURS- WORKED- WEEKLY-OUT .ARRAY 
(X)) 

( Y) ) 

(SELECT  v SELECT 
HOURS- WORKED-WEEKLY-IN. ARRAY 
(X)) 

(Y] 

(EQ  (SELECT  (SELECT  HOURS-WORKED-WEEKLY-OUT .ARRAY 

(X)) 

(SELECT  CURRENT-WEEK-OUT. ARRAY  (X))) 

(SELECT  HOURS-WORKED-THIS- WEEK. ARRAY  (X] 

(EQ  (SUBTRACT  INPUT-MASTER-FILE. LENGTH  1) 

(SUBTRACT  TIME-CARD-FILE. INDEX  1) 

GUTPUT-MASTf.R-FILE  . LENGTH  P  iiCriECK-FILE. LENGTH) 

(EQ  NAME-IN  (QUAL  NAME  TIME-CAPD) 

NAME-OUT 

C  QU  AL  NAME  PAYCHECK)) 

[EQ  GROSS-PAY-TO-DATE-OUT  (PLUS  GROSS- PAY- TO-DATE-IN 

(ROUND  999V99 

(TIMES  WEEKLY-SALARY-IN 
(DIVIDE 

HOURS-WORKED-THIS- WEEK  40] 

(EQ  HOURS-WORKED-TO-DATE-OUT  (PLUS  HOURS-WORKED-TO-DATE-IN 

HOURS-WORKED-THIS- WEEK) ) 

(EQ  CURRENT-WEEK-OUT  (PLUS  1  CURRENT-WEEK-IN ) ) 

(LTQ  1  I) 

(FORALL  Y  (IMPLIES  (AND  (LTQ  1  Y) 

(LTQ  Y  I)) 

(EQ  (SELECT  HOURS- WORKED-WEEKLY-IN  ( Y) ) 

(IF  (EQ  Y  I) 

(SELECT  HOURS-WORKED- WEEKLY- IN 
(Y)) 

(SELECT  HOURS-WORKED-WEEKLY-OUT 
(Y]) 
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Table  VIII-8 


PROOF  OF  VERIFICATION  CONDITION  (6-5)  OF  EXAMPLE  PROGRAM 


[1 

(AND 

[FORALL  X  (IMPLIES  (AND  ( LTQ  1  X) 

(LTQ  X  INPUT-MASTER-FILE. LENGTH) ) 

(AND  (EQ  (SELECT  NAME-IN .ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARL) 

(X))) 

(LTQ  0  (SELECT  CURRENT-WEEK-IN . ARRAY 
(X))) 

(LTQ  (SELECT  CURRENT- WEEK-IN . ARRAY 
(X)) 

51] 

(EQ  IN PUT- MAS  TER- FILE . LENGTH  TIME-CARD-FILE. LENGTH) 

[FORALL 

X 

(implies 

(AND  (LTQ  1  X) 

(LTQ  X  OUTPUT-MASTER-FILE. INDEX) ) 

(AND  (EQ  (SELECT  NAME-IN .ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 

(X)) 

(SELECT  NAME-OUT. ARRAY  (X)) 

(SELECT  (QUAL  NAME .ARRAY  PAYCHECK) 

(X))) 

[EQ  (SELECT  GROSS- PA Y-fO- DATE-OUT .ARRAY  (X)) 

(PLUS  (SELECT  GROSS-PAY-TO-DATE-IN . ARRAY  (X)) 
(ROUND  999 V99  (TIMES  (SELECT 

WEEKLY-SALARY-IN . ARRAY 
(X)  ) 

(DIVIDE  (SELECT 
HOURS- WORKED-THI S-WESK .  ARRAY 

(X)) 

MO] 

[EQ  (SELECT  HOURS-WORKED-TO-DATE-OUT .ARRAY  (X)) 

(PLUS  (SELECT  HOURS- WORKED- TO- DATE- IN .ARRAY 
(X)) 

(SELECT  HOURS- WORKED-THIS-WEEK. ARRAY  (X] 

[EQ  (SELECT  CUR REN  I- WEEK-OUT .ARRAY  (X)) 

(PLUS  1  (SELECT  CURRENT- WEEK-IN .ARRAY  (X] 

[FORALL  Y  (IMPLIES  [AND  (GTQ  1  Y) 

(LTQ  Y  =,2) 

( NEQ  Y  (SELECT 

CURRENT-WEEK-OUT . ARRAY 
(X] 

(EQ  (SELECT  (SELECT 

HOu  RS- WORKED- WEEKLY-OUT . ARRAY 
(X)) 

(Y>) 
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( SELECT  (SELECT 
HOURS-VIORKED- WEEKLY- IN  .ARRAY 
(X)) 

( Y] 

(EQ  (  SELECT  (SELECT  rlOURS-WORKED-WEEKLY-OUT  .  ARRAY 

(X)) 

(SELECT  CURRENT-WEEK-OUT. ARRAY  (X))) 

(SELECT  HOURS-WORKED-THIS-WEEK. ARRAY  (X] 

(EQ  (SUBIRACT  INPUT-MASTER-FILE .  LENGTH  1) 

(SUBTRACT  TIME-CARD-FILE. INDEX  1) 

OUTPUT-MAS TER-FILE. LENGTH  PAYCHECK-FILE . LENGTH ) 

(EQ  NAME-IN  (QUAL  NAME  TI.-iE-CARD) 

NAME- OUT 

(QUAL  NAME  PAYCHECK)) 

[EQ  GROSS-PAY-TO-DATE-OUT  (PLUS  GROSS-PAY-TO-DATE-IN 

(ROUND  999 V99 

(TIMES  WEEKLY-SALARY-IN 
(DIVIDE 

HOURS-WORKED-THIS-WEEK  40] 

(EQ  HOURS- WORKED- rO-DAIE-C-jT  (PLUS  H  OURS- WORK  ED- TO- DATE- IN 

HOURS-WORKED-THIS-WEEK) ) 

(EQ  CURRENT- WEEK-OUT  (PLUS  i  CURRENT- WEEK-IN ) ) 

(LTQ  1  I) 

(FORALL  Y  ( IMPLIES  (AND  (LTQ  1  Y) 

(LTQ  Y  (SUBTRACT  I  1))) 

(EQ  (SELECT  HOURS- WORKED-WEEKLY-OUT  (Y)) 
(SELECT  HOURS- WORKED- WEEKLY- IN  (  Y] 

[2  (FORALL  Y  (IiU LIES  (AND  (LTQ  1  Y) 

(LTQ  Y  (SUBTRACT  I  1))) 

(EQ  ( SELECT  HOURS- WORKED- WEEKLY -OUT  (Y)) 

(SELECT  HOURS- WORK ED- WEEKLY-IN  ( Y] 

L i  (IMPLIES  (AND  (LTQ  1  Y) 

(LTQ  Y  (SUBTRACT  I  1))) 

(EQ  (SELECT  HOURS- WORKED-WEEKLY-OUT  (Y)) 

(SELECT  HOURS- WORK ED- WEEKLY- IN  (  Y] 
l4  (AND  (LTQ  I  Y) 

(LTQ  Y  (SUBTRACT  I  1  ] 

[r;  (EQ  (SELECT  HoURS-WORKED-WEEKLY-OUT  (Y)) 

(SELECT  HOu RS- WORKED- WEEKLY- IN  (Yj 
[  6  (  I.-iPLIES  (NOT  (EQ  Y  I) ) 

(EQ  (SELECT  HOURS-WORKED-WEEKLY-OUT  (Y)) 

(SELECT  HOURS- WORK ED- WEEKLY- IN  (Y] 

17  (EQ  (SELECT  HOURS- WORK ED- WEEKLY- IN  (Y)) 

(SELECT  HOURS- WORK ED -WEEKLY- IN  ( Y ] 

[6  (IMPLIES  (EQ  Y  I) 

(EQ  (SELECT  HOURS- WORK ED- WEEKLY- IN  (Y)) 

(SELECT  HOURS- WORK ED- WEEKLY- IN  (Y] 

L  9  (EQ  (SELEC:  HOU RS- WOhK ED- WEEKLY -IN  .'Y)) 

(IF  (EQ  Y  I) 

(Sk.ECI  hojrs-worked-weekly-in  (y)) 

(SELECT  HOURS-WORKED-WFEKLY-OUT  (Y) 

MO  ;  ir, PLIES  (AND  (LTQ  1  Y) 

(LTQ  Y  (SUBTRACT  I  1) )) 
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(EQ  (SELECT  HOURS- WORKED- WEEKLY-IN  (Y)) 

(IF  (EQ  Y  I) 

(SELECT  HOURS- WORK ED- WEEKLY- IN  (Y)) 
(SELECT  HOURS- WORKED-WEEKLY-OU T  (Y] 

( 1 1  (EQ  Y  I)) 

( 1 2  ( NOT  ( EQ  Y  I) ) ) 

[13  ( EQ  (SELECT  HOURS-WOflKED-WESKLY-OUT  (Y)) 

(SELECT  HJURS-WORKED-WEEKLY-IN  (Y] 

[14  (IMPLIES  (NOT  (EQ  Y  I) ) 

(EQ  (SELECT  HOURS- WORKED- WEEKLY-OUT  (Y)) 
(SELECT  HOURS -WORKED-WEEKLY-IN  ( Y] 

L 1 5  (EQ  (SELECT  HOURS- WORKED-WEEKLY-IN  (Y)) 

(SELECT  HOURS- WORKED-WEEKLY-IN  (Y] 

[16  (IrfPLIES  (EQ  Y  I) 

(EQ  (SELECT  aOURS- WORK ED- WEEKLY-IN  (Y)) 
(SELECT  HOURS- WORKED- WEEKLY- IN  ( Y] 

L 17  (EQ  (SELECT  HOURS- WORKED- WEEKLY-IN  (Y)) 

(IF  (EQ  Y  I) 

(SELECT  HuURS- WORKED-WEEKLY-IN  (Y)) 

(SELECT  HOURS-WORKED-WEEKLY-OUT  (YJ 
L 18  (IMPLIES  (EQ  Y  I) 

(EQ  (SELECT  HOURS- WORKED- WEEKLY- IN  (Y)) 

(IF  (EQ  Y  I) 

(SELECT  HOURS-'WORKED-WEEKLY-IN  (  Y) ) 
(SELECT  HOURS-WORKED-WEEKLY-OUT  (Y] 
[19  (IMPLIES  (OR  (AND  ( LTQ  1  Y) 

( LTQ  Y  (SUBTRACT  I  1))) 

(EQ  Y  I)) 

(EQ  (SELECT  HOURS- WORKED-WEEKLY-IN  ( Y) ) 

(IF  (EQ  Y  I) 

(SELECT  HOURS-WORKED-WEEKLY-IN  ( Y ) ) 
(SELECT  HOURS-WORKED-WEEKLY-OUT  (Yl 

[20  (AND  (LTQ  1  Y) 

(LTQ  Y  (SUBTRACT  I  1] 

(21  (LTQ  Y  I)) 

(22  (OR  (LTQ  Y  (SUBTRACT  I  D) 

(EQ  Y  I))) 

(23  (LTQ  Y  (SUBTRACT  I  1))) 

(24  (L'l  1  Y)) 

L  25  (AND  (LTQ  1  Y) 

(LTQ  Y  (SUbTRACT  I  1] 

(26  (OR  (AND  (LTQ  1  Y) 

(LTQ  Y  (SUBTRACT  I  1)  )  ) 

(EQ  Y  I))) 

[27  (IMPLIES  (LTQ  Y  (SUBTRACT  I  1)1 
(OH  (AND  (LTQ  1  Y) 

(LTQ  Y  (SUBTRACT  I  1)1' 

(EQ  Y  I] 

(28  (EQ  Y  I)) 

(29  (OR  (AND  (LTQ  1  Y) 

(LTQ  Y  (SUBTRACT  I  1))) 

(EQ  Y  I))) 

(30  (IMPLIES  (EQ  Y  I) 
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(OR  (AND  (LTQ  1  Y) 

(LTQ  Y  ( SUBTRACT  I  1))) 

(EQ  Y  I] 

(31  (OH  (  AND  (LTQ  Y) 

(LTQ  Y  ( SUBTRAC  T  I  1))) 

(EQ  Y  I))) 

(30  (EQ  (SELECT  HOURS- WORKED- WEEKLY -IN  (Y)) 

(IE  (EQ  Y  I) 

(SELECT  HoU RS- WORKED- WEEKLY -IN  (Y)) 

(SELECT  HOURS- WORKED- WEEKLY-OUT  (Yj 

l 33  (implies  (and  (ltq  i  y) 

(LTQ  Y  n) 

( EO  (SELECT  H0UES-W3RKED-WEEKLY-IN  (Y)) 

(IE  (EQ  \  I) 

(SELECT  HOURS- WORKED- WEEKLY- IN  (Y)) 

(SELECT  HOURS- WORKED- WEEKLY-OUT  (Y] 

,34  (r  DR  ALL  Y  (IMPLIES  (AND  (LI'Q  1  Y) 

( LTQ  Y  I)) 

(EQ  (SELECT  HOURS- WORK ED- WEEKLY- IN  (Y)) 

(IF  (ED  Y  I) 

(SELECT  HOURS- WORKED- WEEKLY- IN 
(Y)) 

( SELECT  HOURS-WORKSD-WEEKLY-OUT 

(  Y] 

(  35 

(  H  N  l) 

i  FOR  ALL  X  ■  I. -.PLIES  <  AND  'LTQ  1  X) 

!  LTQ  X  INPUT-MA3TER-FILE. LENGTH) ) 

AN"  .'EQ  ,  SELECT  JAME-IN  .ARRAY  (X)) 

SELECT  (QUAL  NAME.  ARRAY  TIME-CARD) 
(X))) 

(LTQ  0  (SELECT  CURRENT-WEEK-IN  .ARRAY 
(X))) 

.'TQ  (SELECT  HjRRSNT-WEEK-IN. ARRAY 
(X)  ) 

■>  *  j 

,  r  IKE- CARD- FILE.  LENGTH) 


X 

f :  -!PL :  f 

an:  ,  q  '•  a 

.  ;  .  x  0 J  V ,-IA  A  TER- FILE.  I N D EX)  A 
(AND  (rQ  (  S.-LKC:  N  AML  -  1 N  .  A  R  PA  Y  (X); 

,  sKI.r  ST  w  1  AL  NAME. ARRAY  TIME-CARD) 

;  X  ■  : 

s  L-.I.EC  T  N AML-OUT  .  ARRAY  (  X )  ) 

(SELECT  (QJAL  NAME. ARRAY  PAYCHECK) 

(  X )  )  ) 

;  .  j  :  SELECT  )•  ROSS  -  PA  Y-TJ- DATE-OUT  .ARRAY  (X)) 

v PLUS  (SELECT  GROSS- PA Y-TO-D ATE- IN . ARRAY  (X); 

••  ((•}•  .  )OVr »  (TIMES  (SELECT 

WEEKLY-SALARY'- IN  .ARRAY 

(X>  ) 


138 


(DIVIDE  (SELECT 
HOURS- WORKED- THIS- WEEK. ARRAY 

(X)) 

40] 

[EQ  (SELECT  HOURS- WORKED-TO-DATE-OUT .ARRAY  (X)) 

(PLUS  (SELECT  HOURS- WORKED-TO-DATE-IN .ARRAY 
(X)) 

(SELECT  HOURS-WORKED-THIS-WEEK. ARRAY  (X] 

[EQ  (SELECT  CURRENT- WEEK-OUT . ARRAY  (X)) 

(PLUS  1  (SELECT  CURRENT-WEEK-IN .ARRAY  ( X j 
[FOR ALL  Y  (IMPLIES  [AND  ( GTQ  1  Y) 

( LTQ  Y  5?) 

( NEQ  Y  (SELECT 

CURRENT-WEEK-OUT .ARRAY 
(X] 

(EQ  (SELECT  (SELECT 

HOURS- WORKED- WEEKLY-OUT. ARRAY 
(X)) 

(Y)) 

(SELECT  (SELECT 
HOURS- WORKED- WEEKLY-IN. ARRAY 
(X)) 

(Y] 

(EQ  (SELECT  (SELECT  HOURS- WORKED-WEEKLY-OUT .ARRAY 

(X)) 

(SELECT  CURRENT-WEEK-OUT. ARRAY  (X))) 

(SELECT  HOURS- WORKED- THIS- WEEK. ARRAY  (X] 

(EQ  (SUBTRACT  INPUT-MAS  TER- FILE. LENGTH  1) 

(  SUBTRACT  rii-lE-CARD-FILE.  INDEX  1) 

OUTPUT-MASTErt-FILE. LENGTH  PAYCHECK-FILE .LENGTH) 

(EQ  NAME- IN  (QUAL  NAME  HmE-CARD) 

N ArtE-OUT 

(QUAL  NAME  PAYCHECK)) 

[EQ  GROSS-PAY-TO-DATE-OUT  (PLUS  GROSS-PAY-TO-DATE-IN 

(ROUND  9°9 V99 

(TIMES  WEEKLY-SALARY-IN 
(DIVIDE 

HOURS-WORKED-THIS-WEEK  40] 

(EO  HOURS-WORKSD-rO-DArS-OUT  (PLUS  HOURS- WORKED-TO-DATE-IN 

HOURS-WORKED-THIS-WEEK) ) 

(EQ  CURRENT-WESK-OUT  (PLUS  1  CURRENT-WEEK-IN)) 

(LTQ  1  I))) 
i  36 
(AND 

[ FORALL  X  (IMPLIES  (AND  (LTQ  1  X) 

(LTQ  X  INPUT-MASTER-FILE. LENGTH) ) 

(AND  (EQ  (SELECT  NAME-IN .ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 
(X))) 

(LTQ  0  (SELECT  CURRENT-WEEK-IN .ARRAY 
(X))) 

(LTQ  (SELECT  CURRE.NT-WEEK-IN.  ARRAY 
(X)) 
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bi  1 

(  EQ  IiMPU  T-MAS  i'ER-FILE  .  LENGTH  TIME-CARD-FILE  .  LENGTH ) 

[ FORALL 
X 

(  IMPLIES 

(AND  (LTQ  1  X) 

eLTQ  X  OUTPUT-MASTER-FILE . INDEX) ) 

(AND  (EQ  (SELECT  NAME-IN . ARRAY  (Xj) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 

(X)) 

(SELECT  NAME-OUT. ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  PAYCHECK) 

(X))) 

l EQ  (SELECT  GROSS- PAY-TO-DATE-OUT .ARRAY  (X)) 

(PLUS  (SELECT  GROSS- PAY-TO-DATE-IN .ARRAY  (X)) 
(ROUND  999 V99  ( TIMES  (SELECT 

QEEKLY-S ALARY- IN .ARRAY 
(X)) 

(DIVIDE  (SELECT 
H0UR3-W0RKED-THIS- WEEK. ARRAY 

(X)) 

90] 

(SELECT  iL'URS- WORK 5D-70-DATE-0UT .ARRAY  (X)) 

(PLUS  (SELECT  HOURS- wORKED-TO-DATE-IN .ARRAY 
(X) ) 

(SELECT  HOURS-WORKED-THIS- WEEK . ARRAY  (X] 

.  Ej  (SELECT  CURRENT-WEEK-OUT. ARRAY  (X)) 

V?LjS  1  (SELECT  CURRENT- WEEK-IN . ARRAY  (X] 

[FORALL  i  IMPLIES  [AND  ( GTQ  1  Y) 

(LTQ  Y  S?) 

( NEQ  Y  (SELECT 

CURRENT- WEEK-OUT. ARRAY 
(X] 

( EQ  (SELECT  (SELECT 

HOURS-WORKED-WEEKLY-OUT. ARRAY 
(X)) 

(  Y)) 

(SELECT  (SELECT 
HOURS- WORKED- WEEKLY-IN. ARRAY 
(X)) 

(Y] 

(  c.Q  Ur.LECr  SELECT  HOURS-WORKED-WEEKLY-OUT  .  ARRAY 

(X) ) 

(SELECT  CURRENT-WEEK-OUT. ARRAY  (X))) 
(SELECT  HOURS- WORKED-THIS- WEEK. ARRAY  (X) 

(EQ  .  GU  SIR  ACT  I  PUT- MAS  TEa-F  ILE .  LENGTH  1) 

Su^IRk::  TlMb-CAuD-FILE.  *  IDEX  1) 
yj  TPJ  r- .-.AC. .  r. «- FILE  .  LENGTH  PAYCHECK-FILE .  LENGTH ) 

(eg  NAME- I »  (QUAL  NAME  TIME-CARD) 

I  A  iE~  c-  - 

(J,A..  JA.lE  PA  (CHECK)! 

..  >h._  co- p ay a . e .  ;r  (plus  -.ross-pay-to-date-in 

; ROUND  990V99 


(TIMES  WEEKLY-SALARY-IN 


(DIVIDE 

HOURS- WORK ED -THIS- WEEK  40] 

(EQ  HOURS-WORKED-TO-DATE-OUT  (PLUS  HOURS-WORKSD-TO-DATE-IN 

HOURS- WORKED- THIS- WEEK ) ) 

( £Q  CURRENT- WEEK-OUT  (PLUS  1  CURRENT-WEEK-IN) ) 

( LTQ  1  I) 

(FORALL  Y  (IMPLIES  (AND  (LTQ  )  Y) 

(LTQ  Y  I)) 

(EQ  (SELECT  HOURS- WORK ED- WEEKLY- IN  (Y)) 

(IF  (EQ  Y  I) 

(SELECT  HOURS- WORKED- WEEKLY- IN 
(Y)) 

(SELECT  HOURS-WORKED-WFEKLY-OUT 
(Y] 
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( IMPLIES 

(NOT  (GT  I  52)) 

(AND 

[ FOhALL  X  (IMPLIES  (AND  (LTQ  1  X) 

(LTQ  X  INPUT-.-1A3TER-FILE. LENGTH) ) 

(AND  (EQ  (SELECT  NAME- IN. ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 
(X))) 

(LTQ  0  (SELECT  CURRENT-WEEK-IN .ARRAY 
(X))) 

(LTQ  (SELECT  CURRENT-WEEK-IN .ARRAY 
(X)) 

51] 

(EQ  INPUT-iiAS TEH-FILE . LENGTH  TIME-CARD-FILE . LENGTH) 

[FORALL 

X 

(IMPLIES 

(AND  (LTQ  1  X) 

(LTQ  X  OUTPUT-MASTSR-FILE . INDEX) ) 

(AND  (EQ  (SELECT  NAME-IM .ARRAY  (X)) 

(SELECT  (QUAL  NAME.  ARRAY  TIME-CARD) 

(X)) 

(SELECT  NAME-O'JT. ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  PAYCHECK) 

(X))) 

[EQ  (SELECT  GR03S-PAY-T0-DATS-0UT .ARRAY  (X)) 

(PLUS  (SELECT  GROSS-PAY- TO-DATK-IN .ARRAY  (X)) 
(ROUND  991V91  (TIMES  (SELECT 

WEEKLY-SALARY-IN .ARRAY 
(X)) 

( DIVIDE 
(SELECT 

HOURS- WORKED-THIS- WEEK. ARRAY 

(X)  ) 

401 

[EQ  (SELECT  HjuRS-WORKED-TO-DATE-OUT .ARRAY  (X)) 

(PLUS  (SELECT  HOURS -WORK ED- TO- DATE- IN .ARRAY 
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38 

( 


(X)) 

(SELECT  HOURS-WORKED-THIS- WEEK. ARRAY 
(X] 

[EQ  (SELECT  CURRENT-WEEK-OUT .ARRAY  (X)) 

(PLUS  1  (SELECT  CURRENT-WEEK-IN .ARRAY  (X] 

[FORALL  Y  (IMPLIES  [AND  (GTQ  1  Y) 

( LTQ  Y  52) 

( NEQ  Y  (SELECT 

CURRENT-WEEK-OUT. ARRAY 
(X] 

(EQ  (SELECT  (SELECT 

HOU  RS- WORKED-WEEKLY-OUT .ARRAY 

(X)) 

(Y)> 

(SELECT  (SELECT 
HOURS-WORKED-WEEKLY-IN. ARRAY 
(X)) 

( Y] 

(EQ  (SELECT  (SELECT  HOURS- WORKED-WEEKLY-OUT . ARRAY 

(X)) 

(SELECT  CURRENT-WEEK-OUT. ARRAY  (X))) 
(SELECT  HOURS-WORKED-THIS- WEEK. ARRAY  (X] 

(EQ  (SUBTRACT  INPUT-MASTER-FILE . LENGTH  1)  __ 

(SUBTRACT  TIME-CARD-FILE. INDEX  1) 

OUTPUT-MASTER-FILE . LENGTH  P AYCHECK-FILE . LENGTH) 

(EQ  NAME-IN  (QUAL  NAME  TIME-CARD) 

NAmE-OUT 

(QUAL  NAME  PAYCHECK)) 

[EQ  GROSS- PAY-TO-DATE-OUT 

(PLUS  GROSS- PAY-TO-DAT E-IN  (ROUND  999V99 

(TIMES  WEEKLY-SALARY-IN 
(DIVIDE 

HOURS- WORKED- THIS- WEEK  40] 

(EQ  HOURS- WORKED-TO- DATE-OUT  (PLUS  HOURS-WOHKED-TO-DATE-IN 

HOURS-WORKED-THIS- WEEK) ) 

(EQ  CUnRENi’- WEEK-OUT  (  P^US  1  CURRENT-WEEK-IN)) 

(LTQ  1  I) 

(FORALL  Y  (IMPLIES  (AND  (LTQ  1  Y) 

(LTQ  Y  I)) 

(EQ  (SELECT  HOURS-WORKED-WEEKLY-IN  (Y)) 

(IF  (EQ  Y  I) 

(SELECT  HOURS-WORKED-WEEKLY-IN 
(Y)) 

(SELECT  HOURS- WORKED-WEEKLY-OUT 
(Y] 

Implies 

[  AND 

[FORALL  X  (IMPLIES  (AND  (LTQ  1  X) 

(LTQ  X  INPUT-MASTER-FILE. LENGTH ) ) 

(AND  (EQ  (SELECT  NAME-IN .ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 
(X))) 


BEST  AVAILABLE  COPY 
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( LTQ  0  (SELECT  CURRENT-WEEK-IN . ARRAY 
(X))) 

(LTQ  (SELECT  CURRENT-WEEK-IN .ARRAY 
(X)) 

51] 

(EQ  INPUT-MAS fEh-EILE. LENGTH  TIME-CARD-FILE . LENGTH ) 

[FORALL 

X 

(IMPLIES 

(AND  (LTQ  1  X) 

(LTQ  X  OUT PUT- MASTER- FILE .INDEX ) ) 

(AND  (EQ  (SELECT  NAME-IN .ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 

(X)) 

(SELECT  NAME-OUT. ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  PAYCHECK) 

(X))) 

[EQ  (SELECT  GROSS- PA Y-TO-DATE-OUT . ARRAY  (X)) 

(PLUS  (SELECT  GROSS-PAY- TO-DATE-IN . ARRAY  (X)) 
(ROUND  999V99  (TIMES  (SELECT 

WEEKLY-SALARY-IN. ARRAY 
(X)) 

(DIVIDE 

(SELECT 

H0UR3-W0RKED-THIS-WEEK. ARRAY 
(X)) 

40] 

L  EQ  (SELECT  HOURS- WORKED-TO-DATE-OUT .ARRAY  (X)) 
(PLUS  (SELECT  riOURS-WORKED-TO-DATE-IN  .ARRAY 
(X)) 

(SELECT  HGURS-WORKED-THIS-WEEK . ARRAY 
(X] 

[EQ  (SELECT  CURRENT-WEEK-OUT .ARRAY  (X)) 

(PLUS  1  (SELECT  CURRENT-WEEK-IN .ARRAY  (X] 
[FORALL  Y  (IMPLIES  [AND  ( GTQ  1  Y) 

(LTQ  Y  52) 

( NEQ  Y  (SELECT 

CURRENT- WEEK-OUT. ARRAY 
(X] 

(EQ  (SELECT  (SELECT 

HOURS-WORKED-WEEKLY-OUT .ARRAY 

(X)  ) 

(Y)) 

(SELECT  (SELECT 
HOURS- WORKED-WEEKLY-IN .ARRAY 


(X)) 

(Yj 

(EQ  (SELECT  (SELECT  HOJ R3- WORK ED- WEEKLY- OUT .ARRAY 

(X)) 

(SELECT  CURRENT-WEEK-CUT. ARRAY  (X))) 
(SELECT  H0UR3-W0RXED-THIS-WEEK . ARRAY  (X] 

(EQ  (SUBTRACT  INPU T-MASTEH-FILE . LENG Tri  1) 

(SUBTRACT  TlriE-CAftD-FILE  .  INDEX  1) 
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OUTPUT-MASTER-FILE .  LENGTH  PAYCHECK-FILE  f  EMCTt-n 
(EQ  NAmE-IN  (QUAL  UAME  TIME-CARD)  FILC •  '-EMGTH5 

NAME-OUT 

(QUAL  NAME  PAYCHECK) ) 

[EQ  GROSS- PA Y-TO-DATE-OUT 

(PLUS  GROSS- PAY-TO-DATE-IN  (ROUND  999V99 

(TIMES  WEEKLY-SALARY-IN 
(DIVIDE 

(CQ  U0UR3-W0RKED-T0-D ATE-OUT  (PLUS  HOuTKL^^ 

(EO  CURRENT- WEEK-OUT  (PLUS  1  CURSEHT-WEEK-rO ™‘THIS-WEEK) > 

( LTQ  II) 

( FORALL  Y  ( Is  jP  LIES  (AND  (LTQ  1  Y) 

(LTQ  Y  (SUBTRACT  I  1))) 

(EQ  (SELECT  HOURS- WORKED- WEEKLY-OUT 
(Y)) 

, T  (SELECT  HOURS- WORKED- WEEKLY- IN  (Yl 

(IMPLIES  J 


(NOT  (GT  I  52)) 

(AND 

[FORALL  X  (IMPLIES  (AND  (LTQ  1  X) 

(LTQ  X  INPUT-MASTER-FILE. LENGTH) ) 
(AND  (EQ  (SELECT  NAME-IN . ARRAY  (X)) 
(SELECT  (QUAL  NAME. ARRAY 
TIME-CARD) 

(X))) 

(LTQ  0  (SELECT  CURRENT- WEEK-IN . ARRAY 
(X))) 

(LTQ  (SELECT  CURRENT-WEEK-IN . ARRAY 
(X)) 


(LQ  InPUT-MASTER-FILE. LENGTH  TIME-CARD-FILE . LENGTH ) 

[FORALL 

X 


(IMPLIES 

(AND  (LTQ  1  X) 

(LTQ  X  OUTPUT-MASTER-FILE. INDEX)) 

(AMD  (EQ  (SELECT  NAME-IN .ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  TIME-CARD) 

(X)) 

(SELECT  NAME-OUT .ARRAY  (X)) 

(SELECT  (QUAL  NAME. ARRAY  PAYCHECK) 

(X))) 

[EQ  (SELECT  GROSS- PA Y-TO- DATE-OUT. ARRAY  (X)) 
(PLUS  (SELECT  GROSS-PA Y-TO-DATS-IN .ARRAY 
(X)) 

(round  9 9 9 vgg 

( TIMES  (SELECT 


WEEKLY-SALARY-IN .ARRAY 
(X)) 

(DIVIDE  (SELECT 
HOURS-WORKED-THIS- WEEK. ARRAY 
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E  T"  r  ABLE  COPY 


(X)) 


40] 

[Eg  (SELECT  HOURS- WORKED- TO- DATE- OUT  .ARRAY  (X)) 
(PLUS  (SELECT  HOURS- WORKED-TO-DATE-IN .ARRAY 

(X)) 

(SELECT  HGURS-WORKED- THIS- WEEK. ARRAY 
(X] 

[EQ  (SELECT  CURRENT-WEEK-OUT .ARRAY  (X)) 

(PLUS  1  (SELECT  CURRENT-WEEK-IN .ARRAY  (X] 
[FORALL  Y  (IMPLIES  [AND  ( GTQ  1  Y) 

( LTQ  Y  52) 

(NEQ  Y  (SELECT 

CURRENT- WEEK-OUT. ARRAY 
(X] 

(EO  (SELECT  (SELECT 

HOURS- WORKED- WEEKLY-OUT. ARRAY 

(X)) 

(Y)) 

(SELECT  (SELECT 
HOURS- WORK  ED- WEEKLY-IN. ARRAY 
(X)) 

( Y] 

(Eg  (SELECT  (SELECT  DURS-WORKED- WEEKLY-OUT . ARRAY 

(X)) 

(SELECT  CURRENT-WEEK-OUT. ARRAY  (X))) 
(SELECT  H0UR3-W0RKED-THIS-WEEK. ARRAY  (X] 

(Eg  (SUBTRACT  INPUT- MASTER- FILE . LENGTH  1) 

(SUBTRACT  TIHE-CAnD-FILE. INDEX  1) 

0UTPUT-rtA3TE.<- FILE. LENGTH  PAYCHECK-FILE. LENGTH) 

(Eg  NAi-iE-IN  (gUAL  NAME  TIME- CARD) 

NAME-OUT 


(gUAL  NAME  PAYCHECK)) 

[Eg  GROSS- PAY-Tu-DATE-OUT 

(PLUS  GROSS-PAY-TJ-DATE-IN 

(ROUND  909 V99  (TIMES  WEEKLY-SAL ARY- IN 

( DIVIDE  HOURS- WORK ED- THIS- WEEK 
40] 

(EO  HUURS-WOrtKED-Tu- DATE- OUT  (PLUS  HOU RS- WORK ED- TO- DATS- IN 

HOURS- WORK ED- THIS- WEEK) ) 
(EQ  CURRENT-WEEK-OUT  (PLUS  1  CURRENI-wEEK-IN)) 

( LTg  1  I) 

(FORALL  Y  (IMPLIES  (AND  (LTg  1  Y) 

(LTQ  Y  I)) 

(EQ  (SELECT  HOURS- WORK ED- WEEKLY- IN 
(Y)) 

(IF  (EO  Y  I) 

(SELECT  r:.  URS- WORKED- WEEKLY -IN 

(  Y) ) 

(SELECT  HOURS- WORKED- WEEKLY-OUT 

( Y] 
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Table  VIII-9 


INFERENCE  RULES  FOR  PROOF  PRESENTED  IN  TABLE  VIII-8 


1-  hyp. 

2'  \  A-  •  -A  An  I-  A^l  <  i  <  n),  1 

3.  inst.  y,  2 

4 .  hyp . 

5.  m.p. , 3,4 

6.  B  h-  A  =5  B,  5 

7.  A  =  A 

8.  B  hA-3  B ,  7 

9.  A  —  x  =  y  A  ~1A  03  x  =  z  = 

x  =  if  A  then  y  else  z 

(definition  of  conditional  expression),  6,  8 

10.  ded  .  ,  4,9 

11.  hyp. 

12.  hyp. 

13.  A,  -A  j-B,  11,  12 

14.  ded.,  12,  13 

15.  A  =  A 

16.  Bh-AioB,  15 

17.  def.  conditional  expression,  16,  14 

18.  ded.,  11,  17 

19.  ADD.  COB  f —  AVCOB,  10,  18 

20.  hyp. 

21 .  A  A B  1 —  B,  20 

22.  x-;yjx  +  1  V  x  =  y  (x,  y  integers),  21 

23.  hyp. 

:m.  A  A  B  h-  B,  20 

25.  A,  B  (—  A  A  B,  23,  24 

26.  B  h  A  V  B,  25 

27.  ded.,  23,  26 

28.  hyp. 

29.  B  | —  A  V  B,  28 
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30.  ded.,  28,  29 

31.  A  V  C,  A  3  B,  C  3  B  h-  B,  22,  27,  30 

32.  m. p. ,  19,  31 

33.  ded.,  20,  32 

34.  gen.  y,  33 

35.  AABt-A,  1 

36.  A,  B  H  A  B,  37,  36 

37.  B  [-  A  3  B,  38 

38.  ded.,  1,  39 


LEGEND 


hyp. 

hypothesis 

Inst. 

instantiation 

VxP(x)  ( —  P(z)  if  Z  is  not  free  in 

P(x) 

gen. 

generalization 

P(x)  |— VzP(z)  if  Z  is  not  free  in 

P(x) 

m.p. 

modus  ponens 

ADB,  A  (—  B 

ded . 

deduction 

(A  H  B)  (—  A  =>  B 

sub. 

substitution 

according  to  free  variable  rules. 
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IX  CONCLUSIONS 


A.  General 

This  work  has  shown  the  feasibility  of  the  verification  of  COBOL 
programs  in  realistic  application  areas.  The  main  result  of  the  project 
has  been  to  uncover  some  major  remaining  difficulties  that  must  be  re¬ 
solved  to  make  verification  an  effective  tool. 

Achievements  of  this  project  are: 

(1)  Decomposition  of  the  verification  process  into  stages, 
making  the  system  easier  to  implement  and  to  interact 
with . 

(2)  A  very  effective  axiomatization  of  the  COBOL  data  structures 
and  control  statements,  that  fits  well  into  the  structure 

of  the  verification  system. 

(3)  A  process  that  yields  verification  conditions  that  are 
simple  to  prove,  although  there  are  many  verification 
conditions  to  prove,  even  for  a  simple  program. 

The  major  problems  of  COBOL  verification  as  encountered  in  this  pro¬ 
ject  are: 

(1)  Verbosity  of  the  programs,  assertions,  and  verification 
conditions . 

(2)  The  semantic  complexity  of  the  COBOL  language. 

These  two  problems  have  a  trade-off  in  their  solutions.  A  verification 
system  that  handles  the  semantic  complexity  directly  makes  the  verifica¬ 
tion  conditions  less  verbose,  but  a  system  that  translates  the  complexity 
into  simpler  units  makes  the  verification  conditions  more  verbose. 

The  remaining  research  involved  in  COBOL  verification  should  be 
aimed  at  making  it  possible  to  verify  bigger,  more  complex  COBOL  programs, 
more  easily  and  with  more  machine  aid.  This  means  doing  basic  research 
in  techniques  to  structure  the  complexity  of  COBOL  verification,  while 
at  the  same  time  engineering  the  developing  system  to  make  things  more 
convenient  for  the  user.  We  believe  that  the  following  tasks  would 
yield  significant  benefits  in  both  of  the  above  areas: 

(1)  Enlarging  the  subset  of  COBOL  amenable  to  verification. 

This  means  dealing  with  the  problem  of  character  strings 
and  their  relation  to  numeric  data. 
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(2)  Engineering  the  parts  of  the  system  to  make  them  easier 
to  use . 

(3)  Research  on  deductive  systems,  including  incremental 
simplification  during  posttransduction  processing  and 
verification  condition  generation. 

(4)  Work  on  techniques  to  help  write  COBOL  programs  that  are 
easier  to  verify.  These  would  include  management  tech¬ 
niques  to  restrict  the  kinds  of  programs  written  and 
possible  minor  syntactic  changes  to  the  language. 

(5)  Extension  of  the  assertion  language  to  make  it  easier 
to  state  abstract  properties  of  COBOL  programs. 

(6)  Exploration  of  the  use  of  data  abstraction  techniques 
to  enable  the  verification  of  large,  structured  COBOL 
programs . 

(7)  Development  of  an  interactive  COBOL  environment  closely 
coupled  with  the  COBOL  verification  system. 

B.  A  Note  on  a  Programming  Environment  for  COBOL 

A  COBOL  verification  system  is  not  like  a  compiler,  because  a  pro¬ 
grammer  cannot  submit  a  program  with  assertions  to  the  verifier  and 
receive  a  verified  program  as  output.  Closely  coupled  interaction  with 
the  verification  system  is  required  at  all  stages  of  the  verification 
process,  and  frequent  changes  to  both  programs  and  assertions  are  to 
be  expected. 

A  program  should  be  developed  for  verification.  Operations  required 
on  these  programs  (eg.,  formal  testing,  symbolic  tracing,  debugging) 

can  be  performed  optimally  under  close  interaction  with  the  programmer. 

25 

I,  has  also  been  substantiated  that  interactive  programming  improves 
program  reliability  and  programmer  productivity. 

Finally,  we  feel  that  programmers  will  not  write  assertions  for 
programs  unless  such  a  task  is  made  easy  for  them  by  their  programming 
environment.  The  need  for  tools  designed  for  this  purpose  is  great. 

We  feel  that  building  these  tools  around  an  interactive  interpreter 
for  COBOL  programs  is  the  best  way  to  proceed  to  the  ultimate  goal  of 
making  program  verification  usable.  Even  if  the  remaining  research 
issues  are  resolved,  it  will  take  much  time  before  the  best  environment 
l.ir  verification  is  achieved.  We  believe  that  enough  is  now  understood 
about  the  nature  of  COBOL  verification  to  enable  an  effective  environ¬ 
ment  to  te  built. 
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GLOSSARY 


Abstraction  -  a  technique  for  hiding  particular  parts  of  a  phenomenon 

(e.g.,  a  programs  behavior)  to  make  the  other  parts  of  that  pheno¬ 
menon  easier  to  understand. 

Assertion  -  a  predicate  in  first-order  logic  concerning  the  values  of 
variables  in  a  program. 

Assertion,  inductive  -  an  assertion  placed  within  the  program  text  to 
break  up  the  program's  flowchart  into  simple  paths  containing  a 
fixed  number  of  program  statements. 

Assertion,  input  -  an  assertion  that  constrains  the  values  of  a  program's 
input  data. 

Assertion,  output  -  an  assertion  that  relates  the  values  of  a  program's 
input  data  to  the  values  of  its  output  data. 

Assertion  language  -  first-order  logic  along  with  some  predefined  func¬ 
tions  that  express  the  semantics  of  domains  that  may  be  related 
to  a  programming  language  (e.g.,  integers,  reals,  strings,  and 
arrays ) . 

Checks,  complle-time  -  any  decidable  restrictions  on  a  program  that  can 
be  placed  on  its  source  code,  i.e.,  detectable  from  the  syntax 
alone . 

Checks,  run-time  -  any  restrictions  on  a  program’s  execution  that  are 
not  decidable  until  the  program  is  executed  with  a  particular  set 
of  input  data. 

Deductive  system  -  a  program  that  attempts  (with  or  without  user  guidance) 
to  generate  a  formal  proof  of  a  verification  condition. 

Language,  real  -  a  programming  language  that  is  used  in  some  kind  of 
software  production. 

Ordering,  dynamic  -  ordering  of  the  execution  of  a  program's  statements, 
which  is  dependent  on  the  input  data. 

Ordering,  lexical  -  ordering  of  statements  in  the  source  code  of  a  program. 

Path  -  a  sequence  of  program  statements  that  is  executed  for  particular 
values  of  the  input  data;  it  can  be  infinite. 

Path,  simple  -  a  path  that  executes  a  fixed,  finite  number  of  program 

statements  for  any  values  of  the  input  data;  a  program's  flowchart 
can  be  broken  up  into  a  set  of  simple  paths. 

Posttransduction  processing  -  translation  of  a  transduced  form  of  a 

program  into  another  internal  form  that  is  suitable  for  verifica¬ 
tion  condition  generation. 


Terms  applying  to  COBOL  alone  are  not  defined  here.  Check  Reference 
12  for  definition. 


Program  verification  -  the  process  of  proving  that  the  behavior  of  a 
program  is  consistent  with  an  input  assertion  and  an  output 
assert  ion . 

Proof  checker  -  a  simple  program  to  check  the  output  of  a  deductive 
system  to  see  if  the  proof  is  logically  sound. 

Semantics  -  the  rules  that  determine  how  any  element  of  a  language  is 
interpreted,  in  terms  of  some  model. 

Simplification  -  application  of  algebraic  and  propositional  rewrite 
rules  to  reduce  the  complexity  of  a  formula. 

Structured  programming  -  a  discipline  for  reducing  the  complexity  of 
programs  by  using  control  primitives  to  guarantee  nested  flow¬ 
charts.  (Note:  this  is  not  Dijkstra's  definition  of  the  term.) 

Subset  -  a  restriction  of  the  syntax  of  a  language  that  is  also  com¬ 
patible  with  the  language's  semantics. 

Syntax  -  the  rules  that,  determine  for  a  given  whether  a  character  string 
is  an  element  of  a  particular  language. 

Termination  -  a  property  of  a  program  stating  that  the  program  finishes 
execution  in  finite  time  for  particular  input  data. 

Termination ,  clean  -  a  property  of  a  program  that  includes  termination 
and  absence  of  run-time  errors 

Transduction  -  translation  of  a  program  into  an  internal  form  defined 
by  a  transduction  grammar. 

Transduction  grammar  -  a  set  of  rules  defining  both  the  syntax  of  a 
language  and  an  algorithm  for  producing  an  internal  form  for  a 
program  in  the  language 

Verification  condition  -  a  logical  formula,  produced  from  a  program 
in  which  assertions  have  been  inserted,  that  is  equivalent  to 
the  logical  consistency  of  the  program  (according  to  some  semantic 
model )  and  the  assertions;  often  referred  to  in  the  plural  (i.e., 
the  verif. cation  conditions  for  a  program). 

Verification  condition  generator  -  a  program  that  takes  a  program  and 
assertions  as  uiput,  and  produces  a  verification  condition. 
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APPENDIX 


CODE  FOB  COBOL  VERIFICATION  SYSTEM 

The  Appendix  contains  two  sections.  The  first  section  contains 
the  INTERLISP  code  to  manipulate  transduction  grammars,  which  was  not 
developed  during  the  current  work  but  was  used  as  part  of  the  system. 
This  code  is  not  documented.  The  second  section  contains  the  INTERLISP 
code  for  the  symbol  table  (ST) ,  posttransduction  processing  (PTP),  and 
verification  condition  generation  (VC).  The  role  of  each  function  is 
briefly  described,  along  with  its  affiliation  with  one  of  the  three 
constituent  modules  above. 
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( F ILECREATED  "  5-JAN-76  13:34:%"  NEWPARSE.;3  1650? 
previous  date:  "  5-JAN-76  1  1:30:47"  NEWPARSE . ; ?) 

( LISPXPRINT  (QUOTE  NEWPARSEOOMS) 

T  T) 

(RPAQJ  NEWPAItSCCOMS  ( (  FNS  «  NEWPARSEFNS) 

(VARS  TLIST  OUTCOUNT  FIRSTRHSCOL  SECONDRHSCOL  PRINTFLG))) 

( RPAQQ  NEWPARSEFNS 

(ABSTRACT  ADDFNS  ADDON  ADDSTATE  COBOL TOKSNFN  COMPLETE 

COMPLETEP  C0MPLI3  COMPUTELOOK  DELFNS  DIF  EARLY 
ERASING-INDICES  EXTRACT  FIND-ERASING-RULES 
FLUSHGRAMMAfi  FLUSHLEFT  GETALT  GETDOT  GETDOTSYMBOL 
GETLHS  GETLOOK  GETORIG  GETORIGPTR  GSTPARSE  OETRULE 
GET T RAN  JOVIALTOKENFN  LEFTSET  MAKEMATRIX  MAKEPARSE 
MAKEPARSE1  NTERMINALP  OUTLINE  POWER-SET  PPC  PREDICT 
PREDICTP  PRETTYGRAMMAR  PRINTGRAMMAR  PRINTGPAMMAR/R 


PRINTSTATESET  PURIFY  PUTRJLE  PUTRULES  PUTTRAN 
PUTTRANS  SAVEGRAM  SCAN  SCANP  SETPARSE  SORTRULES 
TERMINALS  TESTFINAL  TRANSLATE)) 

( DEFINE Q 
( ABS I R AC  T 

[LAnBDA  (INPUT  TjfCENFN) 

(COND 

((EQ  (CAR  (QUOTE  NEWGRAM.iARLOAD) ) 

(QUOTE  N03IND) ) 

(SETQ  NEWGRAMMRLOAD  T) 

(ATTACH  (QUOTE  MROOT) 

NONTERMS) 

(ADDON  (QUOTE  ##ROOT) 

(LIST  (CADR  NONTERrtS) 

( QUOTE  RP AD) ) ) 

(for  NT  in  SPECI ALNONTERMS  do  ( DR E MOVE  NT  NONTERMS) 

(REMPROP  NT  (QUOTE  RULES)) 
(REMPROP  NT  (QUOTE  TRANS))) 

( St T PARSE))) 

(FLuSHLEFT) 

[ FRPLACA  (QUOTE  INPUTSTRING) 

(APPEND  INPUT  (LIST  (QUOTE  RP  AD] 

[for  TOKEN  in  I JPUT  do  (COND 

( ( NTt;\MINALP  TOKEN) 

( APPL f *  TOKEN FN  TOKEN] 

(COND 

( (EARLY) 

(TRANSLATE  (MAKEPARSE))) 

(  T  (  QUO  f  c,  NOGO]) 

( ADDFNS 

[  LAi'iuDA  (X) 

( S^i  Q  NEW? AR3EFNS  (APPEND  NEWPARSEFNS  X  !  i 
(ADDON 

[LA.idDA  (LHS  RuG) 

(COND 

((NOT  (MEMBER  RriS  ( GETP  LHS  (QUOTE  RULES] 

(PJTRULE  LHS  RHS) 

(PUTTRAN  LHS  (QUOTc.  T1  j ) 
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(ADDS! ATE 

[  LAi-idOA  ( LHS  ALT  DOT  ORIG  ORIGPTR  LOOK  PARSELIST ) 

(PROG  NIL 

(SETQ  HA 5:11  TEM  (PACK  (LIST  LHC  (QUOTE  It) 

ALT 

( QUOTE  If) 

DO  I 

(QUOTE  <t) 

ORIG) ) ) 

( 5ETQ  HASHVAL  (GETHASri  HASHITEM) ) 

(COND 

[ HASH VAL  ( SETQ  NEWLOOK  (DIF  LOOK  HASHVAL)) 
(COND 

(NEWLOOK  ( NCONC  HASHVAL  NEWLOOK)) 

(T  (RETURN] 

(T  (SETQ  NEWLOOK  LOOK) 

(PUTHASH  HASHITEM  LOOK))) 

( TCONC  STATESET  (NCONC  (LIST  (CONS  LHS  ALT) 

DO  I 

(CONS  ORIG  ORIGPTR) 
NEWLOOK 1 
PARCEL  I  ST  1 ) 

UOBOLToKENFN 
L  L  Al-jo  DA  (TOKEN) 

( COND 

( (NUMHERP  TO KEN) 

(ADuON  (QUOTE  number) 

(LIST  T  , K EN  )  ,i  ) 

( ( STRING P  TOKEN) 

(ADDON  (QUOTE  string) 

(LIST  TOKEN))) 

( (  L I T AT Oii  TOKEN) 

(ADDON  (QUOTE  symbol) 

(LIST  i'  jKEN  ) )  ) 

( ( eg  (CAR  TJKEN ' 

(QUOTr.  ASSERT)) 
i.  ADDON  (QUOT".  insertion) 

(LIST  TOKEN  )  !  ) 

(T  ( ERROR  "Unexpected  token"  TOKEI'I]) 

(COMPLETE 
[  LAi-i3DA  NIL 

(FOR  STATE  IN  (GET  (GEIGRIGPTR'1 
(GETLHS) ) 

DO  (  PROGN  ( FRPLACD  (QUOT-  TiMPSTORE) 

( CDDDDR  STATE)) 

(ADDPROP  (QUOTE  TEMP STORE ) 

(ADD!  (CADR  STATE)) 

(CAR  STATEPTR) 

T) 

(  ADUST  A  r;-,  (caah  STATE) 

( CDAR  STATE) 

( ADD1  (CADR  STATc.)) 

( CAADDR  STATE) 
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( CDADDR  STATS) 

( CADDDR  STATE) 

(CDR  (QUOTE  TEMPSTORE]) 


(COMPLETEP 
[  LAi-iBDA  NIL 

(AND  (NULL  DOl'SYriBOL) 

(FuEMB  INPUTCHAR  (GETLOOK]) 

(COi-lPLIS 

[LAMBDA  (X  Y) 

(COND 

((NULL  X) 

T) 

((NULL  Y) 

NIL) 

( ( ALPHORDER  (CAR  X) 

(CAR  Y)) 

(COND 

( ( £Q  (CAR  X) 

(CAR  Y)) 

( COMPLIS  (CDR  X) 

(CDR  Y))) 

(T  I))) 

( r  NIL]) 

( COMPUTELOOK 
[LAiiBDA  NIL 

[ SE1Q  TEMPSTORE  ( FNTH  (GETRULE  (GETLHS) 

(GETALT)) 

(PLUS  2  (GETDOT] 

(COND 

[TEMPSTORE  ( COND 

( ( GETP  (CAR  TEMPSTORE) 

(QUOTE  RULES)) 

(LEFTSET  (CAR  TEMPSTORE))) 

(T  (LIST  (CAR  TEMPSTORE] 

(T  (GETLDjKJ) 

(  DELFNS 

[  LAiiBDA  (X) 

(SETQ  NEWP ARSiFNS  (FOR  Z  IN  NEtfPARSEFNS  UNLESS  (MSMiB  Z  X) 

COLLECT  Z]) 

(DIF 

[LAhdDA  (X  Y) 

(FOR  Z  IN  X  UNLESS  (F.1EMB  Z  Y)  COLLECT  Z]) 

(EARLY 

[ LAiiBDA  NIL 
(PROG  NIL 

(Sc-TQ  STATESCT  (CONS)) 

(CLRHA3H) 

(ADDSTATE  (CAR  NON1ERMS) 

1  0  1  NIL  (CONS  (QUOTE  RPAD) 

NIL)) 

[FOR  INPUTCHAR  IN  INPUTSTRING  AS  INPUTX  FROM  1 
DO 

( PROGN  [FOR  STATEPTR  ON  (CAR  5TATESET) 
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DO  (COME: 

( ( PREDICTP) 

( PREDICT ) ) 

( ( COI-1PLETEP) 

(COMPLETE] 

[COND 

( PRINTFL3 
( COND 

((EQ  PRINTFLG  (QUOTE  ALL)) 

(PRIN1  INP'JTX) 

(SPACES  2) 

( CJ.JD 

( ( ILE33P  ( PRIM  1  (LENGTH  (CAR  5T ATESET ) ) ) 
10) 

( SPACES  1))) 

(SPACES  2) 

(PRINT  INPUTCHAR] 

( T  ( PRIM  1  INPUTCHAR) 

(COND 

((EQ  INPUTCHAR  (QUOTE  RP AD) ) 

(TERPRI) ) 

(T  (SPACES  31 

( SLTQ  OLDSr ATESET  ST ATESET) 

( SET Q  3 r ATESET  (CONS)) 

( CLRHASH ) 

[  FOR  ST  A TCPTR  ON  (CAR  OLDST ATESET) 

DO  (COND 

( ( SCANP) 

(SCAN] 

(COND 

((CAR  .u  ATESET) 

( FRPLACD  (QUOTE  PREDLIST ) 

NIL)) 

(T  (PRINT  (LIST  (QUOTE  ST ATESET) 

(ADD1  INPUTX) 

(QUOTE  IS) 

(QUOTE  EMPTY))) 

(RETURN  NIL] 

(  TEE  TE I N  AL  j  ) 

.  ASI NO- IND I CES 
[  LAMP DA  ( RHS ) 

(for  X  in  RHS  as  I  from  1  bind  (TEMP)  when  TEMP(FAS50C  X 


ERASING-RULES) 

collect  <1  !  TEMP> i ) 

v  l.  X  TRACT 

i  A...1DA  (NT  :<H3  TRAN  INDICES  ANSWERS) 

.for-  Ti 

in  (QUOL>.  (  ri  17  T ■  TR  TS  Tb  T 7  T6  Tq  T 10))  as  RHST 
in  HH  i’  N  from  1 
bind  ((SUbC.ISr  ,11-)! 

Dh"LE( LIS  I  N I  .) ' 

(I.UQo  ).'  (TI  !■  TR  TU  YS  in  V  T3  T9  10)  )1 
T-..MP 
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do  (CONu 

[ ( SETQ  TEMP  ( FA330C  N  INDICES)) 

(TCONC  SUB  (CONS  TI  ( CADDDR  TEMP] 

(T  (TCONC  SUB  (CONS  TI  (CAR  TJ))) 

(SETQ  TJ  ( CDR  TJ)) 

( TCONC  DRULE  R.4ST ) ) ) 

finally  [TCONC  ANSWERS  (LIST  ( QUOTE  PUTRULE) 

(KWOTE  NT) 

(KWOTE  (CAR  DRULE] 

( TCONC  ANSWERS  (LIST  (QUOTE  PUTTRAN) 

(KWOTE  NT) 

(KWOTE  (SUBLIS  (CAR  SUB) 

TRAN  T]) 

( FIND-ERASING-RULES 
[LAMdDA  (NONTCKMS) 

(for  NT  bind  ((R  <NIL>))  in  NOUTERmS 

do  (for  Rri3  in  (GETP  NT  ’RULES)  as  TR  in  (GETP  NT  TRANS) 
as  I  from  1  when  RHS=NIL 
do  ( TCONC  R  <NT  I  TR> ) ) 
finally  (RETURN  R:1]) 

( FLUSriGri  AiinAR 
[LAuBDA  NIL 
[  CON  0 

(  (  NEQ  (CAR  (  QUOIc.  NdNTERMS)) 

(QUOTE  NOBIND)) 

( PROGN  (FOR  NT  IN  NONTERhS  DO  (REMPROP  NT  (QUOTE  RULES)) 

(REMPROP  NT  (QUOTE  TRANS))) 

( SETQ  NONT CRMS  NIL] 

( RPAQQ  NONTERMS  NIL]) 

(FLUSriLEFT 
[  LAi-iBDA  NIL 

(FOR  Z  IN  NONTERnS  DO  (REMPROP  Z  (QUOTE  LEFTS:.!) ) ) 

( FOR  Z  IN  3PECIALN0NTERM3  DO  (REMPROP  L  (QUOTE  LEFTSET]) 
(GETALT 

[  LAiiBDA  NIL 

( CDAAR  3TATEPTR] ) 

(GETDOT 

[LArtBDA  NIL 

(CADAH  Sf ATEPTR ] ) 

(GETDOTSYhBOL 
[  LAi-iaDA  NIL 

(StTQ  TEMPSTORE  ( FNTH  (GETHULE  ( GETLHS) 

(GETALT)) 

{ ADD  1  (GETDOT] 

( COND 

( TEmPSIORE  (CAR  TEMPSTORE]) 

( GETLBo 

[LAMBDA  NIL 

( CAAAh  ST ATEPTR] ) 

(GETLOOK 
[  LAriODA  NIL 

(CADDDR  (CAR  o  TATEPTR] ) 

( GEiORIG 
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i.  LA.-iBDA  NIL 

(  CAADDR  (CAR  G.'ATEPTR]  ) 

(GEIORIGPTH 
[LAMBDA  Nib 

i CDADDR  (CAH  ST ATEPTR] ) 

(GETpARSE 

[LAnBDA  (STATE) 

(COND 

( STATE  (CDDDLR  STATE) ) 

(T  ( CDDDDR  (CAR  STATSPTR]) 

( GETR’JLE 

[LAmuLA  it, nS  ALT) 

(Carl  (FNTH  (GETP  LHC  ( QUO."  ■  RULES)) 

ALT]) 

( GET  IRAN 

[  LA. irfDA  (Lrii  ALT) 

(CAR  ( NTH  (GET?  LUG  (QUOi's.  TRANS)) 

ALT  ] ) 

( jovial:  .kenfn 

(  LAj-J.ADA  i  T.  KEN) 

(  CONG 

!  (  A  j.  :dE  R  P  TuKEN  ) 

(ADDON  f  QUOTE  number) 

(list  TOKEN))) 

( ’ AHj  (LITATGM  TOKEN) 

(SC  (NCHAR3  TOKEN) 

1 )  ' 

i.'OOU.N  ( Q ,  :  letter) 

(LIST  TOKEN/)) 

( v  LI  i'ATUii  TOKEN) 

(ADDON  (QUOTu  symbol) 

(LIST  TOKEN) ) ) 

(T  ( c-RROR  "Unexpected  token"  TOKEN]) 

LEKISf, . 

. LAMuDA  (X) 

( CO  NO 

UGL.V  X  '.J;*.--  LEFTSET) )  ) 
v  T  (  PHU'J  (  J.'FA  .< ! 

(OAK  LMAi  SIX  X) 

FO«  N:  IN  SOFAR 
L'J  !  PROG  (PTR) 

(33 TQ  PTR  (CONS)) 

(LCONC  PTR  ( GETP  NT  (QUOTE  LEFTSET))) 

(FOR  LSY.'i  IN  (CAR  PTR) 

DO  (FOR  1  IN  (GETP  LSYM  (QUOTE  LEFTSET) ) 
UNLESS  (ME, SB  Z  (CAR  PTR)) 

DO  ( TCONC  PTR  Z ) ) ) 

(°.J T  NT  (QUOTE  LEFTSET) 

(FOR  Z  M  (GETP  NT  (QUOTE  LEFTSET)) 
UNLESS  (GETP  Z  (QUOTE  RULES)) 
COLLECT  Z) 

(GETP  X  (QUOTE  LEFTSET ] ) 

,TA\EMATRIX 
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[LAmBDA  (X) 

(PROG  (LSYmLISD 

(FOR  RULEALT  IS  (GEIP  X  (QUOT^  RULES) ) 

UNLESS  ( ME  MB  (CAR  RULEALT) 

LSYMLIST) 

DO  (SEIQ  LSYMLIST  (CONS  (CAR  RULEALT) 

LSYMLIST))) 

(PUT  X  ( QUOTE  LEFTSET) 

LSYMLIST) 

(SETQ  SOFAR  (CONS  X  3GFAR) ) 

(FOR  LSYm  IN  LSYMLIST  WHEN  (AND  (GETP  LSYM  ( QUOTE  HULF3) ) 

(NOT  (MEnB  LSY-i  SO^AR))) 

00  (MAKEMATRIK  LSYm]) 

( MAKEP ARSE 
[  LAMBDA  NIL 

(MAKEPAR3E1  (CAR  (CAR  3TATE3ET]) 

( MAKEPARSE 1 

[LAmBDA  (STATE) 

(CONS  (CONS  ( CAAh  STATE) 

(CDAR  STATE)) 

(FOR  SY-iBOL  IN  (GETRULE  (CAAR  STATE) 

(CDAR  STATE)) 

AS  I  FR OH  J 
COLLECT  (COND 

((NOT  (GETP  SYMBOL  ( QUOTE  RULES))) 

SYMBOL) 

(T  (MAKEPARSE1  (CAR  (GET  ( CDDDDR  STATE) 

I]) 

(NTERMINALF 

[LAmBDA  (TOKElO 

(NULL  (GETP  TOKEN  (QUOTu  TERMINAL]) 

( OUTLI  vi. 

[LAmBDA  (3) 

(  CO  NO 

[  (  EQ  (CiiC0,<1  S) 

13) 

( SSi'Q  O'JTCOJNT  0) 

( PRIN1  ( PACKC  (QUOTE  (13  10] 

(T  (SETQ  OUTCOUN I  ( IPLUS  OUTCOUNT  (NCHARS  3))) 

(PRIN1  3]) 

( POWER-SET 
[LAmBDA  (S) 

(if  S 


tnen  (for  X  bind  ((R  <NIL>))  in  (POWER-SET  S::1) 
do  (rCONC  R  X) 

( TCONC  R  <S:  1  r  X>)' 
finally  (RETURN  R:  D) 
else  < NIL > j ) 

(  PRC 

[LAmBDA  ( P) 

(FOR  X  IN  P  WHEN  ( EQ  ( PROG  1  (PRINT  X) 

(SPACES  1)) 

(QUOTE  J.)) 
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i  TdpRi  1  > 


n .  .  i 

.  i. A.  :-RA  N  i .. 

;  A  L  H  ”  :  Jv  PSiDLI^f) 


:  r ,  . )  il 

;  •  '■ .  ATEPTH )  ) 

j\i  (  .'OMP'JTCLOjK)  ) 

TN  HHSALTS  AS  I  FRO.i 


1  DO  ( ADDSTATE  DOTSYMBOL  I  0  INPUTX 

( CDR  (QUOTE  PREDLIST) ) 
LOOKY]) 


i  :.a  N 

,oL.  ^  ri .  i  A I .  T  S  IE  IT  (CLIO  DOTSY.-iBOL  (  GETD0T3YI130L )  ) 

(QUO To  RULES]) 

Ph..  T  .  Y  1 R  Am i  .A  n 

:  LAi-iiDA  (  r  I  RSV  dE-OL  E.iCO.JDRHSCOL ) 


v  i  'TILL  r  I  ROT RrfSC JL) 

:  con- 

(1SQ  (CAR  (QUOP-.  FIR3TR1SC0L)  ) 

(UuOi'.i  NOBIND)) 

( S~.rQ  rtRCiiUSCOL  20)) 

:  r  (Sn-i'y  rlRSTHNJCOL  (CAR  (QUOTE  FIH3TRHSC0L] 

i  cont 

( (  N  JLL  SECONDRHSCOL) 

( COi'lD 

<;  ( b'.Q  (CAR  (QUOTE  ScXONDRHSCOL ) ) 
l QUOTE  NOSIND)  ) 

(SEl'Q  SECONDRHSCOL  40)) 

(I  (SETQ  3&C0NDRH3C0L  (CAR  (QUOTE  SECONDRHSCOL] 
[OJTL-.  Tr  ( PACKC  (QUOTE  (1]] 

[FOR  NT  IN  NON  TERi-.S 
Tj  (  OUTL  l  Nr,  NT) 

( OU  TLIN (Q'JO  To  i  :  =  )) 

(  r  OR  i  RH3T  (  RHSTX(  GETP  NT  (QUOTE  TRANS] 

IN  ME  TP  NT  (QUOTE  RULES)) 
lJ  (S.-  'Q  RriST  (CAR  RH3TX) ) 

UiitLE  (1LE33P  OUTCO'JNT  FIR3TRHSC0L) 

JO  (  Od  TLIN  j  ( QUOTE  J  ))) 

(FOR  -  IN  HNS  DO  ( OUTLINE  ( QUOTE  i  )) 
(OUTLI IE  E)) 

(CO  NO 

(UCREATERP  SECONDRHSCOL  0) 

( WHILE  ( ILESoP  OUTCOUNT  SECONDRHSCOL) 
DO  (OUTLINE  (QUOTE  %  ))) 

(PRIN1  RHST) ) ) 

(OUTLINE  (PACKC  (QUOTE  (13] 

(PACKC  (QUOTE  (0]) 

PRIM  TGiLu-i.iAH 
i  LA-'ioDA  (N  UJIi-RMS) 

(  TH  R  D  M  ) 

(  Tr.:'  t’RI ) 

(  1‘ERPRJ  ) 
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(  TERPRI) 

(FOR  NT  IN  NONTERMS 
DO  (TeRPRI) 

(PRINT  NT) 

(FOR  X  IN  (GETP  NT  (QUOTE  RULES) )  AS  Y 
IN  (GETP  NT  (QUOTE  TRANS)) 

DO  (PRIN1  (QUOTE  #)) 

[COtID 

(X  (SPACES  2) 

(FOR  TOKEN  IN  X  DO  (PRItll  TOKEN) 

(SPACES  1] 

(TERPRI) 

( PRINTDEF  (CLISPIFY  Y  T) 

3) 

(TERPRI) ) 

(TERPRI) 

(PRINT  (QUOTE _ ]) 

(PRINTGRAMnAR/R 

[LAMBDA  (NONTERMS  FILENAME  TRANS) 

(COND 

(FILENAME  (OUTFILE  FILENAME))) 

(PRINT  ( QUOTc,  )) 

(PRIN1  (QUOTE  . spacing*  1)) 

(TERPRI) 

(PRINT  (QUOTE  .nofill)) 

(PRINT  (QUOTE  .nojustify ) ) 

(PRIN1  ( QUOTE  .tab?  stops?  8,16,24,32,40)) 

(TERPRI) 

(FOR  NT  IN  UjtIT ERM3 
DO  (PRINT  NI) 

[FOR  X  IN  (GETP  NT  (QUOTE  RULES))  AS  Y 
IN  (GETP  NT  (QUOTE  TRANS)) 

DO  (PRIN1  (QUOTE  =)) 

[COND 

(X  (SPACES  2) 

(FOR  TOKEN  IN  X  DO  (PRIN1  TOKEN) 

(SPACES  1] 

(TERPRI) 

(COND 

(TRANS  (PRINTDEF  (CLISPIFY  Y  T) 

3) 

(TERPRI] 

(PRIN1  (QUOTE  .blank?  1)) 

(TEHPRI) 

(PRINT  (QUOTE - )) 

( PRIN1  (QUOTE  .blank?  1)) 

(TERPRI) ) 

(COND 

(FILENAME  (CLOSSF  FILENAME]) 

( PRINTS  TATE  SET 
[  LAi'iiDA  NIL 

(FOR  STATEPTR  ON  (CAR  i ’ATESET) 

DO  ( PRJGN  (PRINT  (LIST  ( GETLHS) 
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( GETALT) 

(getdot) 

( GETORIG) 

( GETLOOK ] ) 

( PURIFY 

[LArtoDA  (NONTEnMS) 

(PROG  ( ( ANSWERS  (LIST  MIL)) 

( ERA3I MG-RULSS  ( FIND-ERA3ING-RULES  NONTERMS))) 

[for  NT  in  NON  TERMS 
do  ( CO.'JD 

( [ NEQ  (FLSNGTH  (GETP  NT  ( QUOTE  RULES))) 

(-LENGTH  (GETP  NT  (QUOTE  TRANS] 

(HELP  NT 

'  does  not  nave  the  sane  number  of  transductions  as  ri^ht  hand  sides.")) 

(for  RH3  in  (GETP  NT  ( QUOTE  RULES))  as  TRAN 
in  (GETP  NT  ( QUOTE  TRANS)) 

1:  • for  IMuICES  in  (POWER-SET  ( ERASING -INDICES 

RHS) ) 

when  INDICES 

Jo  (EXTRACT  T  RHS  TRAN  INDICES  ANSWERS] 

(for  X  in  (CAP  ANSWERS)  do  (EVAL  X)) 

(for  ER  in  ERASING- RULES 
Jo  v  T  (CAP  ER) 

(QUOTE  ;’RANS) 

(for  X  in  (GETP  (CAR  ER) 

(QUOTE  RULES)) 
at  Y  in  (GETP  (CAR  Efi ) 

(QUOTE  TRANS)) 
when  X  collect  Y)) 

(PIT  (CAR  c.R) 

( QUOTE  RULES ) 

C'or  X  in  (GETP  (CAR  ER) 

(QUOTE  RULES)) 
when  X  collect  X]) 

v  ?•,  T  c  uLE 

.  -  A  '-..  A  ( LH:>  RHS) 


(  •  OR  (  EG  (  M:i  (QUO!  .  NDNi'jRMS)  ) 

N...PHD) 

(NULL  NGN  TERMS) ) 

(SSTQ  NONTcRrtS  (LIST  LHS) ) ) 

( r  <  coni) 

( (  N  J  T  ( .lE'IB  LHS  NON  TERMS)) 

(  NCuNCI  MON  TERMS  LNSl) 

I PUTRULES 
t  LAi-iGDA  NUM 
(  PROG  ( .»  j 

(FOR  I  FROM  P  TO  NUM  WHEN  ( PUTRULE  (ARG  NUM  1) 

(ARG  NUM  I)) 

O'  (GET Q  NT  (ARG  NUM  1))) 
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( RE r URN  NT]) 

(PUTTRAN 

L  LAmBDA  U  i.-iAN) 

(ADDPROP  X  ( QUO TE  TRANS) 

Tran  3 ) 

(PUT TRANS 
[LAmBDA  NUm 

(FOR  I  r'riOM  2  TO  NUrt  DO  (PUTTRAN  ( AR 3  NUM  1) 

( ART  NUM  I]) 

( SAT  EG RAM 

[LAMBDA  (X  3UPPRE33-SORT) 

[COND 

((NOT  SJPPRtoS-SORT) 

(SORT  (CDR  NONTERMS] 

(SET  (PACK  (LIST  X  (QUOTi  COrtS))) 

(QUOTE  ([COMS  * ( LIST  (CONS  ( QUOTE  IFPROP) 

(CONS  (QUOTE  (RULES  TRANS)) 
NOtITERMS] 

(VARS  SPECIALNONTERMS  NONTERMS  SPECI ALFWAMES] 

(MAKEFILE  X]) 

(SCAN 

[LAMBDA  NIL 

(ADDSTATE  ( GETLH3) 

(GETALT) 

( ADD t  (GETDOT)) 

(GETORIG) 

(GETORIGPTR) 

(GETLOOK) 

(GE  TP  ARSED 

( 3CANP 

[LAmBDA  nil 

(EQ  INPUTCrlAR  (  GETD0T3YM30L] ) 

( SE  TP  Aii  St 

[LAmBDA  NIL 

(PJT  ( QUOTE  fl? AD) 

(QUOTE  TERMINAL) 

(QUOTE  RP AD) ) 

(for  NT  in  NON  TERMS 

do  (for  RULE  in  ( GETP  NT  (QUOTE  RULES)) 
do  (for  TOKEN  in  RULE 
do  ( COND 

((AND  ;  r  < "  TOKEN  NONTERMS) ) 

..  ->T  ( MEMl-  TOKEN  SPECIALNONTERMS))) 
(PUT  TOKEN  (QUOTE  TERMINAL) 

TOKEN]) 

(S0RTRULE3 

[LAmBDA  ( NON TtnMS ) 

(FOR  NT  IN  NONTERiiS  BIND  PAIRS 

DO  ( SETQ  PAIRS  (FOR  X  IN  (GETP  NT  (QUOTE  RULES))  AS  Y 
IN  (GETP  NT  (QUOTE  TRANS)) 

COLLECT  (CONS  X  Y))) 

[SORT  PAIRS  (FUNCTION  (LAMBDA  (A  3) 

(COMPLIS  (CAR  A) 
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(CAR  B] 

(PUT  NT  ( QUOTE  RULES) 

'(FOR  X  IN  PAIRS  COLLECT  (CAR  X))) 

(PUT  NT  (QUOTi  TRANS) 

/(n  (FOR  y  IN  PAIRS  COLLECT  (CDR  y] ) 

(terminals  j 

[lambda  nil 

(PROG  (ALLRHS) 

[FOR  NT  IN  NONTERMS  DO  (FOR  RULE  IN  ( GETP  NT  (QUOTE  RULES)) 

,  „no  tm  D0  (SETQ  ALLRHS  (APPEND  RULE  ALLRHS] 

(fOR  NT  IN  NONTERMS  DO  (DREMOVE  NT  ALLRHS)) 

(SORT  ALLRHS)  .  _  . 

(RETURN  (FOR  (TOKEN  LAST TOKEN)  IN  ALLRHS 

WHEN  (NEQ  TOKEN  LASTTOKEN)  COLLECT  (SETQ  LASTTOKEN 

TOKEN) 

(.v,r„Tj„  TOKEN]) 

\  i  to  I r INAL 

[LAMBDA  NIL 

( PROGN  (SETQ  STATEPTR  (CAR  S TATESET) ) 

(COND 

((AND  (EQ  ( GETLHS) 

(CAR  NONTERMS)) 

(EQ  (GETALT) 

1) 

(EQ  (GETDOT) 

2)) 

(QUOTE  SUCCESS!]) 

( TRAN SLAT E 
[  LAt-iBDA  (  p) 

(COND 

( ( NLISTP  P) 

P) 

((EQ  (CAR  P) 

( QUOTE  ASSERT)) 

D  \ 


(T  ( A P P L I  (LIST 


(QUOTE  LAMBDA) 
TLIST 
(GETTRAN 


) 

( RPAQQ 
( RPAQQ 
(RPAQQ 
(RPAQQ 
( RPAQQ 
( DECLARE: 


(FOR  PX  IN 


(CAAR  P) 

( CDAR  P))) 
(CDR  P)  COLLECT 


(TRANSLATE  PX]) 


TLIST  ( T 1  T2 
OUT COUNT  0) 

FIR  SI’RHSCOL  12) 
3EC0NDRH5C0L  -1) 
PRINTFLG  ALL) 
DONTCOPy 


T3  14  T5  T6  T7  T8  T9  T10) ) 


( v I LEM A P  (NIL  (891  16329  (ABSTRACT  903  .  1566)  (ADDFNS  1570  .  1639) 
•.ADDON  1643  .  1777)  (ADDSTATE  178  1  .  2393)  ( COBOLTOKENFN  2397  .  2796) 
UOmPLETE  2800  .  3206)  (COMPLETE  3210  .  3293)  (COMPLIS  3?97  3532) 

(COriPUTELOOK  353b  .  3821  )  ( DELFNS  3825  .  3927)  (DIF  3931  .”4000)  (EARLY 
4004  .  5^09 )  (ERASING-INDICES  5213  .  5367)  (EXTRACT  5371  .  6057)  ( 
r  IND-c-R AsING-RlJLE 3  506 1  .  6304)  ( FLUSHGRAMilAR  6308  .  6559)  (FLUSHLEFT 


ST  AVAILABLE  COPY 
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o jo3  .  6706)  (GETALT  6710  .  6756)  (GETDOT  6759  •  6804)  ( GETDOTSYMBOL 
6o03  .  6966)  (GETLHS  6970  .  7015)  (GETLOOK  7019  •  7071)  (GETORIG  7076 
.  7127)  ( GErORIGPTR  7131  •  7186)  (GETPARSE  7190  .  7293)  (GETRtJLE  7297 
.  7382)  ( GET  l'R  AN  7386  .  7469)  ( JOVIALTOKENFN  7473  .  7814)  ( LEFTSET 
7313  .  8385)  UAKEMATRIX  8389  .  8827)  (MAKEPARSE  3831  .  38Q4)  ( 
.lAKEPARiEI  8398  .  9196)  ( NTeRMINALP  9200  .  9271)  (OUTLINE  9?75  .  9480) 
( ?0«ER-SEi  94o4  .  96*1)  (  PJC  9645  .  9782)  ( PREDICT  9766  .  10913)  ( 
PRtDICTP  10017  •  10117)  (PRETIYORArt.JAR  10121  .  11104)  ( PRINTGRAMMAR 
11108  .  11582)  ( PRINTGRAHi-iArt/R  11536  .  12393)  ( PRINTSTATESET  12397 
.  12532)  (PURIFY  12530  .  13525)  ( PUTRULE  13529  .  13799)  (PUTPULES 
13803  •  13932)  (PUTi'RAN  13936  .  14958)  (PUTTRANS  14062  .  *4159)  ( 
SA7EGRAM  14163  •  14472)  ( SCAN  14476  .  14638)  ( SCANP  14642  .  14698) 
(3ETPARSE  14702  .  15040)  (SORTitULES  15049  .  15450)  (TERMINALS  15454 
.  15841)  ( TESl’FINAL  15345  .  16938)  (TRANSLATE  1607°  .  16326))))) 

STOP 
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#ADDCORRESPONDING$  [SENTENCE;  PAIR;] 

remarks:  PTP  -  Processes  an  ADD  CORRESPONDING  statement, 
called  by:  SENTENCES  CAN' 

CORRESPAIRS  [X,Y;  XSONS,  YSONS,  XSON ,  YSON ; ] 

remarks:  PTP  -  Returns  list  of  dotted  pairs  of  corresponding  elementary 

items  of  X  and  Y. 

called  by:  #ADDCORRE S PCM D I N G$ ,  CORRESPAIRS,  #MOVECORRESPOND ING$ , 
#SUBTRACTCORRESPONDING$ 

SONS  [QUALNAME;  X;] 

remarks:  ST  -  Returns  the  list  of  sons  for  a  qualified  data  item, 
called  by:  CORRESPAIRS,  ELEMITEMSOF 

COMPLETELIST  [QUALNAME;  X;] 

remarks:  ST  -  Returns  the  completely  qualified  name  of  a  data  item, 
called  by:  SONS ,  PICTURE*,  LEVEL*,  OCCURS*,  VALUE* 

QUAL  [QUALNAME;;] 

remarks:  ST  -  Appends  (QUAL)  to  a  data  name  if  it  is  unqualified, 
called  by:  COMPLETELIST,  AMBIGUOUS 

AMBIGUOUS  [NAME;  X;] 

remarks:  ST  -  returns  T  if  a  name  is  an  ambiguous  data  reference, 

NIL  otherwise, 
called  by:  COMPLETELIST 

QUALIFIEROK  [QUALLIST,  PREDLIST;  Z;] 

remarks:  ST  -  returns  T  if  a  qualified  name  (QUALLIST)  isnot  in 
conflict  with  a  predecessor  list  (PREDLIST). 
called  by:  AMBIGUOUS,  QUALIFIEROK,  COMPLETELIST,  MULTIPLE 

#ASSERT  [SENTENCE;;] 

remarks:  PTP  -  Processes  an  ASSERT  statement, 
called  by :  SENTENCESCAN 

ASSERT:  [SENTENCE,  PTR ;  X;] 

remarks :  PTP  -  Processes  an  ASSERT  statement, 

called  by:  #ASSERT,  ASSERT1 

MAXS I ZE  *  ( QUALN AME ; ; ] 

remarks:  ST  -  Returns  the  maximum  size  of  a  qualified  data  item, 

called  by:  ASSERT1 ,  #SET$,  #SETROUNDED$ 

MAXSIZE  [PIC;  X , Y , L , R ; ] 

remarks:  ST  -  Returns  the  maximum  size  of  a  PICTURE  specification, 
called  by:  MAXSIZE* 

PICTURE*  r QUALNAME ; ; ] 

remarks:  ST  -  Returns  the  PICTURE  specification  for  a  qualified  data 
name. 

called  by:  MAXSIZE* 

#1F  [SENT;  ARG1 ,  ARG2 ; ] 

remarks:  PTP  -  Processes  an  IF  statement, 

called  by:  SENTENCESCAN 
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SENTENCES CAN  [TEXT;  SENT;] 

remarks:  FTP  -  Scans  a  program  to  do  post-transductlon  processing, 
called  by:  #IF,  SENTENCESCAN,  ^PERFORM,  PREPROCESS,  VC 

^OPENIN’  [L;  ; '] 

remarks:  FTP  -  Processes  an  OPEN  INPUT  statement, 
called  by:  SENTENCESCAN,  tfOPENOUT 

#OPEN  OUT  I L ;  ;  ]  “  -  — 

remarks:  PTP  -  Processes  an  OPEN  OUTPUT  statement, 
called  by:  SENTENCESCAN 

"READ  [L;  NAME,  ITEM;] 

remarks:  PTP  -  Processes  a  READ  statement, 

called  by:  SENTENCESCAN 

ELEMITEMSOF  [X; ; ] 

remarks :  PTP  -  Returns  the  elementary  items  of  a  group  data  item, 
called  by:  tfREAD,  ELEMITEMSOF,  #WR I TE 

RKCORDL I S  T  IN AME ; ; ] 

remarks:  ST  -  Returns  the  list  of  records  associated  with  a  given 
file  name. 

called  by:  £READ ,  RECORDNAME 

£  WRITE  [  T  j ;  INDKXNAME,  LENGTIINAME,  ITEM;] 

remarks:  PTP  -  Processes  a  WRITE  statement. 

called  hy:  SENTENCESCAN 


PILE  [NAME;;] 

remarks:  ST  -  Returns  the  file  associated  with  a  record. 

called  by:  "WR I TE 

F PERFORM  [SENT;  ASSRT,  INDEX,  FIRSTVALUE,  STEP,  TERMINATION;  FLATSECTEXT] 
remarks:  PTP  -  Processes  a  PERFORM  statement, 
called  by:  SENTENCESCAN 

!•'  I jAT'FKN PARAS  |  AliPROG  :  PARA ;  ] 

remarks:  PTP  -  Eliminates  paragraph  structure  from  a  COBOL  program 

producing  a  list  of  sentences, 
called  by:  ^PERFORM,  PREPROCESS ,  VC 

GATH ERPA RAS  [LI,  L2,  TEXT;  X,  Y;] 

remarks:  PTP  -  Gathers  text  in  TEXT  between  the  labels  LI  and  L2. 

called  by :  # PERFORM 

"SKT$  [SENTENCE;;] 

remarks:  PTP  -  Processes  a  SET$  (assignment)  statement, 
called  by:  SENTENCESCAN 

?S  ETRO UN OED$  [ S  KNTEN CE ; ; ] 

remarks:  IM’P  -  Processes  a  SETROUN DED$  (rounded  assignment) 
statement. 

called  by:  SENTENCESCAN 
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#MOVECORRES  PCX  DIN  G$  [SENTENCE;  PAIR!  ] 

remarks:  PTP  -  Processes  a  MOVE  CORRESPONDING  statement, 
called  by:  SENTENCESCAN 

#S U BTRACTCORRES PCN D IN G$  [SENTENCE;  PAIR;] 

remarks:  PTP  -  Processes  a  SUBTRACT  CORRESPONDING  statement, 

called  by:  SENTENCESCAN 

CHANGELABEL  [SENTENCE;;  SECL1ST] 

i-emarks:  PTP  -  Replaces  labels  in  sentences  by  their  fully-qualified 

(i.e.,  <paragraph  name,  section  name>)  versions, 
called  by:  CHANGELABEL,  LABELMAKER 

GETNEWLABEL  [LABEL;;  SECLIST,  SEUION] 

remarks:  PTP  -  Returns  tie  fully-qualified  version  of  a  given  label, 

called  by:  CHANGELABEL 

ERR  [X;;] 

remarks:  PTP  -  Error  routine.  Prints  argument, 

called  by:  GETNEWLABEL 

LASTPARA  [SEC;  SECTION;  ABPROG] 

remarks:  PTP  -  Returns  the  fully-qualified  label  of  the  last 

paragraph  In  a  given  section, 
called  by:  CHANGELABEL 

COBOL VCG  [PATHLIST;  PATH;] 

remarks:  VC  -  Actual  verification  condition  generator  operating  on 
the  output  of  the  path  analyzer, 
called  by :  VC 

VCG1  { PATH ,  FORM ; ; ] 

remarks:  VC  -  Recursive  auxiliary  function  used  by  COBOLVCG. 
called  by:  COBOLVCG,  VCG1 

CON  VERT  [PIC;  X,Y,7.1,Z,$$TEM1,  $$TEM2,Z2;] 

remarks:  ST  -  Canonicali zes  a  PICTURE  specification, 

called  by:  INSERT DATA ,  1NSERT771TEM 

UEBUGPRINT  [WHAT,  WHERE,  WPEN ; ;FLAT ] 

remarks:  PTP  -  Auxil .ary  debugging  function, 

called  by :  PREPKOCE  S 

PPR  is  not  defined. 

ELEMENT ARYP  | DATADESCR I PT ION ; ; ] 

remarks:  ST  -  Returns  T  if  a  variable  name  represents  an 
elementary  data  item,  NIL  otherwise, 
called  by:  GETRECORD 

ERASETABLE  (;  X,  Y:  SYMBOL TABLE ,  TYPES,  VALUES] 
remarks:  ST  -  Initializes  symbol  table, 

called  by: 
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FETCHIjABELAS  S  ERT I  ON  S  [ABPROG;  PAHA;  LABELA8SERTLIST] 

remarks:  ST  -  Constructs  A-list  (LABELASSERTLIST)  whose  entries  are 

of  form  <paraname ,  assertion>  of  all  labelled  assertions. 

called  by:  VC 

ISASSERT  [X;;] 

remarks:  PTP  -  Predicate  testing  for  list  of  form  (ASSERT . ) 

called  by:  FETCHLABELASSERTIONS ,  PATHANAL 

FILENAME  [RECORD;;]  - . 

remarks :  PTP  -  Returns  file  name  corresponding  to  a  given  record 

called  by: 

FLATTENS ECT IONS  [ABPROG;  SECTION ; ] 

remarks:  PTP  -  Flattens  abstract  program  into  a  list  of  paragraphs, 

called  by:  PREPROCESS,  VC 

GETRECORD  [GARBAGE,  LEVELLIST,  NAMELIST;  CURRENTLEVEL ,  CURREN TRECORD ,  DUMMY, 

SSTEM1,  $$TEM2;  ] 

remarks;  ST  -  Constructs  a  tree-structured  data  declaration  out  of 
a  flat  list. 

called  by:  GETRECORD,  GETRECORD* 

IN SER'I'DATA  [NAME,  PREDECESSORS,  PICTURE,  LEVEL,  SONLIST,  OCCURS,  VALUE] 
remarks:  ST  -  Inserts  a  data  item  into  the  symbol  table. 

called  by:  GETRECORD 

NNULLATOM  [A;;] 

remarks:  ST  -  Returns  T  if  the  argument  is  not  a  null  atom,  NIL 

o  therwise . 

called  by :  INSERTDATA 
PICTUREOK  [PIC;  X;  PICTURECHARS] 

remarks:  ST  -  Returns  T  if  PIC  is  a  permissible  PICTURE  specification 
NIL  otherwise. 

called  by:  INSERTDATA,  INSERT77 ITEM 
MULTIPLE  [NAME,  QUALS ;  X;] 

remarks:  ST  -  Returns  T  if  NAME  and  QUALS  are  conflicting  qualified 

data  names.  .....  . . 

called  by:  INSERTDATA,  INSERT77ITEM 

INSERT VALUE  [FULLNAME,  VALUEEXP;;  VALUES] 

remarks:  ST  -  Inserts  a  value  designation  into  the  symbol  value, 
called  by:  INSERTDATA,  IN SERT77ITEM  .  ...... 

I N SERTS YMOOL  [ NAME ; ; SYMBOLTABLE ] 

remarks:  ST  -  Inserts  a  variable  into  the  symbol  table. 

called  by:  INSERTDATA,  INSERT77ITEM,  INSERTFILE,  INSERTPARAGRAPH , 

IN  SERTHECORD ,  INSERTSECTION 

GETSONS  [TREE;  X;] 

remarks:  ST  -  Returns  list  of  names  of  sons  of  a  group  data  item, 
called  by:  GETRECORD 
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GETRECORD*  [RECORDLIST;  X,  7 7 DECS ,  DATADECS ,  Y; 3 

remarks;  ST  -  Takes  a  list  containing  possibly  many  data  declarations 
and  turns  it  into  a  declaration  bill. 

called  by: 

INSERT77 ITEM  [NAME,  PICTURE,  OCCURS,  VALUE;;] 

remarks:  ST  -  Inserts  a  77-item  into  the  symbol  table, 
called  by:  GETRECORD* 

INSERTFILE  [NAME,  RECORDLIST;;] 

remarks:  ST  -  Inserts  a  file  name,  and  its  corresponding  record  list, 
into  the  symbol  table. 

called  by : 

INSERTPARAGRAPH  [NAME,  SECTION;;] 

remarks:  ST  -  Inserts  a  paragraph  name  into  the  symbol  table, 
called  by : 

INSERTRECORD  [NAME,  FILE;;] 

remarks:  ST  -  Inserts  a  record  name  into  the  symbol  table, 
called  by : 

INSERTSECTION  [NAME;;] 

remarks:  ST  -  Inserts  a  section  name  into  the  symbol  table, 
called  by: 

LABELMAKER  [ABPROG;  SECLIST,  PARALIST,  SECTION ,  PARAGRAPH,  SECTION, 
PARAGRAPH,  PARANAME ,  SECNAME ; ] 

remarks:  PTP  -  Replaces  all  label  references  (and  labels)  in  program 
by  their  fully-qualified  [paraname,  sectionname]  versions 
called  by:  PREPROCESS,  VC 

LEVEL*  [QUALNAME;;] 

remarks:  ST  -  Returns  the  level  number  of  a  qualified  data  item, 
called  by: 

OCCURS  *  l QU ALN  AME ; | ] 

remarks;  ST  -  Returns  the  number  of  occurrences  of  a  qualified  data 
l  tem. 

called  by: 

PATHANAL  [SENTLIST,  ACCUM,  SENT;  X;  PATHLIST,  TEMP,  LABELASSERTLIST] 

remarks;  VC  -  Constructs  from  list  of  sentences  a  list  (PATHLIST) 
of  paths  in  the  program,  each  path  beginning  and  ending 
with  an  assertion, 
called  by:  PATHANAL,  VC 

PREPROCESS  [ABPROG,  FLAG;  FLATSECTEXT ,  FLATPARATEXT ,  TEXT;] 

remarks:  PTP  -  Transforms  abstract  program,  readying  it  for  path 

analysis  (Now  obsolete,  superceded  by  VC). 

called  by: 
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RECORDN AME  | FILE; ; 1 

remarks:  ST  -  Returns  the  record  name  corresponding  to  a  file. 

called  by: 

S  ECT I  ON'  US  T  ( N  AME  ;  ;  ] 

remarks:  ST  -  Returns  the  list  oi  sections  for  a  given  paragraph  name. 

called  by: 

SECT ION P  IN AME; ; 1 

remarks:  ST  -  Returns  T  if  the  argument  is  a  section  name,  NIL 
otherwi se. 

called  bv: 

VALUE*  IQUALNAME;;! 

remarks:  ST  -  Returns  the  VALUE  expression  for  a  qualified  data  item. 

called  by: 

VC  !  AjBPKOC  ;  IWTUlAST ,  FLATSECTEXT ,  LABELASSERTLIST;  SCANOUT,  PATHANALOUT  , 

VCOITJ 

remarks :  VC  k  PTP  -  Takes  raw  abstract  program  as  input;  performs 

preprocessing,  path  generation,  and  verification  condition 
generation.  Returns  list  (VCOUT)  of  verification  conditions. 

called  by: 

ZAP  l;;  Z/Z,  MIKE/A] 

remarks:  l’TP  -  Internal  debugging  routine, 

called  bv  : 
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Code 


( . ILECREATED  "10-JAN-75  17:34:56"  PREPSYMBOL . ; 4  ?855R 
changes  to:  L  ABELiTAKER  SENTENCESCAN 
previous  date:  "  9-JAN-76  20:51:25"  PREPSYMBOL . • 3) 

(  LISPXPRINT  (QUOTE  PREPSYMEOLCOMS )  ~ 

T  T) 

[RPAQQ  PREPSYi'iflOLCOMS  ( ( FNS  *  PREPSYMBOLFNS ) 

(DECLARh:  DONTEVAL@LOAD  DOEVAL^COMPILE  DOMTCOPY  COMPILERVARS 
(ADDVARS  ( NLAMA) 

(NLAML  DEBUGPRIMT] 

(RPAQQ  PREPSYi'iBOLFNS 

( // ADDCO  R  R  ES  PON  DING  $  #  ASSERT  PIF  //MOVECORRESPONDING*  40P5NIN 

//OPENOUT  //PERFORM  //READ  //SET$  tfSETROUNDEDt 
//SU8TRACTC0R  RES  PONDING};  //WRITE  AMBIGUOUS 
A3SSRT1  CHANG6LABEL  COBOLVCG  COMPLETELIST 
CONVERT  CORRESPAIRS  DEBUGPRINT  ELEMENTARYP 
EL EMITEM30F  ERASETABLE  ERR 
FETCHL A BEL ASSERTIONS  FILE  FILENAME 
FLATTENPARAS  FLATTEN SECTIONS  GATHERPARAS 
GETNEWLABEL  GETRECORD  GETRECORD*  GETSONS 
INSERT77ITEM  INSERTDATA  INSERTFILE 
INSERTP ARAGRAPH  INSERTRECORD  INSERTSECTION 
INSEHTSYMBOL  INSERTVALUE  ISASSERT 
LABEL.1AKER  LASTPARA  LEVEL*  MAXSIZE 
MAXSIZE*  MULTIPLE  NtiULLATOM  OCCURS* 
PATHANAL  PICTURE*  PICTUREOK  PREPROCESS 
QUAL  QUALIFIEROK  RECORDLIST  RECORDNAME 
SECTIONLIST  SECTIONP  SENTEMCESCAN  SONS 
VALUE*  VC  VCG1  ZAP)) 

S.DEFINEQ 

( //  A  D  0  CO  R  R  f,  3  PO  iJ  0 1 NG  A 

[  LAi-i6DA  ( SENTENCE) 

(FOR  PAIR  IN  (CORRESPAIRS  (CADR  SENTENCE) 

( CADDR  SENTENCE)) 

COLLECT  (LIST  (COND 

( ( CADDDR  SENTENCE) 

(QUOTE  SSTROUNDEDS ) ) 

(T  (QUOTE  SET$))) 

( CDR  PAIR) 

(LIST  (QUOTE  PLUS) 

(CDR  PAIR) 

(CAR  PAIR)) 

(CAR  ( CDDDDR  SENTENCE]) 

( //ASSERT’ 

[LAMBDA  (SENTENCE) 

(ASSShTI  SENTENCE) 

(LIST  SENTENCE]) 

(  //IF 

[LAMBDA  (SENT) 

(PROG  ( ARC  1  AKQ2) 

[SETQ  ArtGI  (SENTENCESCAN  (LIST  (CADDR  SENT] 

[SEI’Q  ARG2  (SENTENCESCAN  (LIST  (CADDDR  SENT] 

r  COND 

((CDR  ARG1) 


COLLECT  (LIST 
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IS&TQ  Anu  I  VLlii  vyuuic,  BLOOM 
ARG1 ) ) ) 

(T  (SETQ  ARG1  (CAR  ARG1] 

L  COND 

( ( CDR  ARG2) 

(SETQ  ARG2  (LIST  ( QUOTE  BLOCK) 

ARG2) ) ) 

(T  (SETQ  ARG2  (CAR  ARG2) 

(RETURN  (LIST  (LIST  (QUOTE  IF) 

(CADR  SENT) 

ARG1  ARG2] ) 

( #ri0VEC0RR£3P0NDING$ 
t  LAiiBDA  (SENTENCE) 

( FOR  PAIR  IN  (CORRE3PAIRS  (CADR  SENTENCE) 

(CADDR  SENTENCE)) 

COLLECT  (LIST  (QUOTE  3£T$) 

(CDR  PAIR) 

(CAR  PAIR) 

NIL]) 

UOPENIN 
[LAmBDA  (L) 

(LIST  (LIST  (QUOTE  SET$) 

(MKATOM  (CONCAT  (CADR  L) 

(QUOTE  .INDEX))) 

0]) 

UOPENOJT 
[LAnBDA  (L) 

( #OP£NIN  L]) 

UPERFORcl 

[LAnBDA  ( SENT) 

(PROG  ((ASSET  (CADDR  ( CDDR  SENT))) 

INDEX  FIRSfVALUE  STEP  TERMINATION ) 

(COND 

[(SQ  (CADR  SENT) 

(QUOTE  TIMES) ) 

(SETQ  INDEX  ( GENSYM) ) 

(RETURN 

(LIST 

(CONS 

(QUOTE  BLOCK) 

(SENTENCESCAN 

(APPEND  [LIST  (LIST  (QUOTE  SET*) 

INDEX  1) 

ASSri  r 

(LIST  (QUOTE  IF) 

(LIST  (QUOTE  GT) 

INDEX 

(CADDDR  SENT) ) 
(QUOTE  (ENDPERFORM)) 
(QUOTE  (NEXT] 

(FLATTENPARAS  (GATHERPARAS 

(CADR  (CADDR  SENT)) 
(CADDR  (CADDR  SENT)) 
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(  VRtAD 


FLATSECTEXT) ) 

(LIST  (LIST  ( QUOTE  SETt ) 

INDEX 

(LIST  (QUOTE  PLUS) 

INDEX  1)) 

(LIST  (QUOTE  LOOPA3SERT) 

ASSRT] 

f(EQ  (CADR  St NT) 

(QUO It  VARYING) ) 

(SEIQ  INDEX  (CAK  ( CADDDR  SENT))) 

( St  TQ  FIRST VALUE  (CADR  (CADDDR  SENT))) 

(SEi’Q  STEP  ( CADDR  (CADDDR  SENT))) 

(St.iQ  TERMINATION  (CADDDR  (CrtDDDR  SENT))) 

(F.c.T  URN 
(LIST 
(CONS 

(QUO:'..  BLOCK) 

( StNIt  'iCESCAN 

(APPEND  [LIST  (LIST  (QUOTE  SET*) 

INDEX  EIRSTVALUE) 

AS  CRT 

(LIST  ( QUOTE  IF) 

TERMINATION 
(QUOTE  (  ENDPEh’FORM) ) 
(QUOTE  (NEXT] 

(FLAT TEN PAR AS  ( GATHER PARAS 

(CADR  (CADDR  SENT)) 

( CADDR  (CADDR  SENT) ) 
FLATSECTEXT) ) 

((.LSI  (LIST  (QUOTE  SETf ) 

INDEX 

(LIST  (QUOTE  PLUS) 

INDEX  STEP) ) 

(LIST  (QUOTE  LOOPASSERT) 

(LIST  (QUOTE  ASSERT) 
ASSRT ] 

{  v  EQUAL  [CADR  Sr. NT) 

( QUO f  .  ( ONCE  $  ' ) > 

At  1  ij  RN 

(LIS!  (v.  .)Ni  <  „  !jT  .  BLOCK) 

( SEN  TE. JCE3CA.N 

( F L AT  TEN PAR A  C  ( GATIERPARA3 

(CADR  (CADDR  SENT) ) 
(CADDR  (CADDR  SENT)) 
FLATSECTEXT] 

(  T  (  QUO  A.  ( STRANGE  SYNTAX  I;J  BLOCK  STM  FENCE  ] ) 

)  (L.) 

!(fJA-.E  (MKAT.)M  (C-1NCAT  ( CADR  L) 

(QUOTE  .INDEX] 

-  N  CD  JS 

LIS  !  (LIS  l  (  QUO  T  t  SET$  ) 

NAME 
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IQUOiC.  t'LUo; 

NAME  1 ) ) 

(LIST  (QUOTE  IF) 

[LIST  (QUOTE  GT) 

NAME 

(MK ATOM  (CONCAT  (CADR  L) 

(QUOTE  .LENGTH] 

(CADDDR  L) 

( QUOTE  (NEXT] 

(FOR  ITEM  IN  [ ELEMITEMSOF  (CAR  ( REC0RDLI3T  (CADR  L] 

COLLECT 

(LIST  ( QUOTE  3ET$) 

ITEM 

(LIST  ( QUOTE  SELECT) 

(CONS  (QUOTE  OUAL) 

(CONS  ( MKATOM  (CONCAT  (CADR  ITEM) 

(QUOTE  .ARRAY))) 

(CDDR  ITEM))) 

(LIST  NAME)) 

NIL]) 

( #3EI$ 

[LAMBDA  (SENTENCE) 

(LIST  ( CO.JD 

[(CADDDR  SENTENCE) 

(LIST  (QUOTE  IF) 

(LIST  (QUOr-I  GT) 

(LIST  (QUOTE  ABS) 

(LIST  (QUOTE  TRUNCATE) 

(CADR  SENTENCE) 

(CADDR  SENTENCE))) 

(MAXSIZE*  (CADR  SENTENCE) ) ) 

(CADDDR  SENTENCE) 

(LIST  (QUOTl  ASSIGN) 

(CADR  SENTENCE) 

(LIST  (QUOTE  TRUNCATE) 

(CADR  SENTENCE) 

(CADDR  SENTENCE] 

(T  (LIST  (QUOTc.  AICIGN) 

(CADR  SENTENCE) 

(LIST  (QUOTE  TRUNCATE) 

(CADR  SENTENCE) 

(CADDR  SENTENCE] ) 

(tfSd,TrtOJUDED$ 

LLArtBDA  (SENTENCE) 

(LIST  (COi'ID 

[(CADDDR  SENTENCE) 

(LIST  (QUOTE  IF) 

(LIST  (QUOTE  GT) 

(LIST  (QUOTE  ABS) 

(LIST  (QUOTE  ROUND) 

(CADR  SENTENCE) 

(CADDR  SENTENCE))) 

(MAXSIZE*  (CADR  SENTENCE))) 


(C/iDDDR  SENTENCE) 

(LIST  (  QJO  f  _  ASS  CGfJ) 

(CADR  5e,N  TENGE) 

( list  (quote  round) 

(CADR  SENTENCE) 

(CADDR  SENTENCE] 

(  r  (  LIST  (QUO!’’.  ASSIGN) 

(CADR  SENTENCE) 

(LIST  (QUOD  ROUND) 

(CADR  SENTENCE) 

(CADDR  SENTENCE]) 

( //SUBTRACT CORRESPONDING^ 

[LAMBDA  (SENTENCE) 

(FOR  PAIR  IN  (C0RKESPAIR3  (CADR  SENTENCE) 

(CADDR  SENTENCE)) 

COLLECT  (LIST  (COND 

( ( CADDDR  SENTENCE) 

(QUOf-.  SETRGUNDEDt) ) 

(T  (QUOTE  3.-.T3))) 

( CDR  PAIR) 

(LIST  ( QUO  I1-  SUBTRACT) 

(CDR  PAIR) 

( CArt  PAIR)) 

(CAR  (CDDDSR  SENTENCE]) 

( 4 NRI  i  o 

LLAi-.SDA  (L) 

(PROS  [[  INDEXNA^l,  (MKATOM  (CONCAT  (FILE  (CADR  D) 

(QUOTE  .INDEX] 

(LENGTriNA.iL  (MKATOM  (CONCAT  (FILE  (CADR  L)) 

(QUOTE  .LENGTH] 

( NCONC 

(LIST  (LIST  (QUOTE  o'.T.f) 

INDEXNAME 

(LIST  (QUOTE  PLUS) 

INDEX NAME  1)) 

(LIST  (QUOTi  SETS) 

LENGHNA.-lE 
(LIST  ( QUO Ti  PLUS) 

LENG  T.iNAME  1))) 

("OH  ITEM  IN  ( ELCMITEMSOF  (CADR  D) 

COLLECT 

(LIST  (  QUOi  SET$) 

(LIST  (QUOTE  SELECT) 

(CONS  (QUOTE  QUAD 

(CONS  (MKATOM  (CONCAT  (CADR  ITEM) 

(QUOTE  .ARRAY))) 

( CDDR  ITEM))) 

(LIST  INDEXNAME ) ) 

ITEM  NIL]) 

(  N. [Su  JuS 

[_  LAruOA  (  N  Ai  iE ) 

i  *  -ico opt s  i  n smo  ,  o'.tnor  qualified  or  unqualified, 
and  returns  t  if  it  is  an  ambiguous  data  reference) 
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(ShTQ  NAh£  (QUAL  NAME) ) 

(GREAT SR P  (FOR  X  IN  (GETP  (CADR  NAME) 

( QUO IE  SLEM$) ) 

COUNT  (QUALIFIEROK  ( CDDR  NAME) 
(CAR  X))) 


1]) 

( ASSERT  1 

[LA11BDA  (SENTENCE  PTR) 

(CO  NO 

((NULL  SENTENCE ) ) 

((ATOM  SENTENCE)) 

[(  £Q  (CAR  Sc.Ntc.NCE ) 

(QUOTl.  .-iAXSIZE)  ) 

(RPLACA  PTR  (MAXSIZE*  (CADR  SENTENCE] 

(T  (FOR  X  ON  ( CDR  Sc-NTENCS)  DO  ( ASSERT  1  (CAR  X) 

X]) 


(CHANGELABEL 

[ LAmbDA  (SENTENCE) 

(CO  NO 

((NULL  SENTENCE)) 

((ATOM  SENTENCE) ) 

(T  (SELECTS  (CAH  SENTENCE) 

(READ  ( CHANGELABEL  (CADDDR  SENTENCE))) 

(IF  ( CHANGEL ABEL  ( CADDR  SENTENCE) ) 

( CHANGELABEL  (CADDDR  SENTENCE) ) ) 

[GO  (RPLACA  (CDR  SENTENCE) 

(GETNEWLABEL  (CADR  SSNTENCEl 
(3ET$  (CHANGELABEL  (CADDDR  SENTENCE))) 
(SETROuNDED$  (CHANGELABEL  (CADDDR  SENTENCE) ' ) 
[DO?  (RPLACA  (CDR  SENTENCE) 

(GETNEWLABEL  (CADR  SENTENCE))) 
(RPLACA  (CDDR  SENTENCE) 

( COND 

((MEMR  (C^DDR  SENTENCE) 

SECLIST) 

(LASTPARA  (CADDR  SENTENCE))) 

(T  ( GETNEWLABEL  (CADDR  SENTENCE] 
( PERFORM  (CHANGELABEL  (CADDR  SENTENCE))) 

NIL,  J ) 

(  COBOL VCG 

[LA.-.bDA  (PATBLISi) 

(CONS  (QUOTE  AND) 

(FOR  PATH  I.<  PATHLIST  COLLECT  ( VCG  1  (CDR  PATH) 

(CADAR  PATH]) 


(  CO.iPLETc.LIST 

[  LAiiaDA  (QUALNAME) 

(  SETQ  QUALi  AP  E  (QUAL  QUALMA.iE) ) 

(COMO 

( ( AMBIGUOUS  QuALNAilE) 

(HELP  QuALNAME  "anbia;uous  reference’)) 
(T  (FOR  X  IN  (GETP  (CADR  QUALNAME) 

(QUOTE  £LEm$) ) 

U.ITIu  ( QUALIFIEROK  (CDDR  QUALNAME) 


/ 
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(CAR  X)) 


FINALLY  (COND 

[X  (RETURN  (CONS  (CADR  QUALNAME) 

(CAR  X] 

(T  (HELP  QUALNAME  "is  not  in  symbol  table']) 

( CONVERT 

LLAiidDA  (PIC) 

(IF  (NULL  PIC) 

THiN  NIL 
ELSE 

(PROG  (X  (Y  (LIST  NIL)) 

Z1) 

(SEIQ  X  (UNPACK  PIC)) 

(WHILE  (LISTP  X) 

DO  ( SELECTQ  (CAR  X) 

((9  V  P  S  X) 

(NCONC1  Y  (CAR  X)) 

(SSTQ  X  ( CDR  X))) 

Ci(  ( SET 3  X  (CDR  X)) 

( SETQ  Z1 

(PACK  (FOR  Z  IN  OLD  X 

UNTIL  (EQ  Z  (QUOTE  %))) 
COLLECT  Z))) 

(SETQ  X  (CDR  X)) 

(IF  (NOT  (NUMBERP  ZD) 

THEN  (HELP  Z1 

■'bad  iterative  picture'')) 
(PROG  L(Z2  (CAR  (LAST  Y] 

( RPTQ  (SUB1  ZD 

( NCONC1  Y  Z2] 

(HELP  PIC  bad  picture  specification  ))) 
(RETURN  (PACK  (CDR  Y]) 

( QORRE5PAIRS 
LLAmBDA  (X  Y) 

(PROG  ( XSONS  YSONS) 

(Si ETQ  XSOwS  (SONS  X)) 

(SETQ  (SONS  (SONS  Y)) 

(  COND 

[(AND  XSO.D  YSONS) 

( RETURN  (FOR  XSQN  IN  XSONS 

JOIN  (FOR  YSON  IN  YSONS 

WHEN  ( EQ  (CADR  XSON) 

(CADR  YSON)) 

JOIN  ( C0RRE3PAIRS  XSON  YSON 1 

(  (  OR  XSOiiS  YSONS) 

NIL) 

(I  ( FD TURN  (LIST  (CONS  X  Y] ) 

l  DEB J JPRIN  ( 

L  NLA.-i.jDA  (rtrlAT  .Oi-Rii  WHEN) 

!  Pit  JO  Nii. 

(  CONj 

(  (  WHEN  FLAG) 

(  IEkPRI  ) 


)) 


(PRINT  (  QUOTE  — — 

( TERPRI ) 

( PRINT  WHERE) 

(TtnPRI ) 

( TERPRI ) 

( PPR  (EVAL  WHAT))) 

(T  NIL]) 

( ELEMEN  TARYP 

[LAubDA  ( DATADESCHIPTION )  (*  tells  whether  a  »iven 

data  description  Is  of 
an  elementary  item) 

( CADDR  DATADfcSCHIPTION  ] ) 

( ELEMIfEMSOF 
L  LAuBDA  (X) 

(  CONu 

((FOR  SOW  IN  (SONS  X)  JOIN  ( ELEMITEMSOF  SON))) 

(T  (LIST  X]) 

( EHA3ETABLE 
t  LAuBDA  NIL 

(*  initializes  the  symboltable  by  clearing  the 
property  lists  of  all  names  in  the  symboltable,  then 
clears  the  variable  symboltable. 

mast  be  done  when  performing  two  parses  in  a  row) 

(FOR  X  IN  SYuBOLTABLE  DO  (FOR  Y  IN  TYPES  DO  (REMPROP  X  Y))) 

(SETQ  SYuBOLTABLE) 

( SETQ  TALLIES] ) 

(  EnR 

[LAnoDA  (X) 

(PRINT  X) 

( RETFROil] ) 

( FETCHL ABEL ASSERTIONS 
[ LAuBDA  (AbPROG) 

(FOR  PARA  IN  ABPROG  WHEN  ( ISAS3EKT  (CADDP  PARA)) 

DO  ( SET 3  LABEL ASSEETLIST  (CONS  (CONS  (CADR  PARA) 

(CADDR  PARA)) 

L  ABEL ASS ERTLI ST ] ) 

(FILE 

[  LAiiBDA  (NAilE)  (*  returns  the  file 

correspond im?  to  a  liven 
record  name) 

(GET?  NAME  ( QUOTE  REC0RD$ ] ) 

(FILENAME 

[LAuBDA  (RECORD) 

( QbOTc.  FILENAME]) 

( FLAT  1 Ew PARAS 
L  LA.-idDA  (AtPROG) 

(FOR  PARA  IN  ABPROG  JOIN  (APPEND  (CDDR  PARA]) 

( FLAT  I tNSECTIONo 
[LAuBDA  (ABPROG) 

(FOR  SECTION  IN  ( CDR  ABPROG)  JOIN  (APPEND  (CDDR  SECTION  ] ) 

(  GATHErPAiiAS 

[  LA.  10DA  (LI  L2  TtXT) 

(FOR  X  ON  TtXT  WH^N  (EQUAL  (CADAR  X) 
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LI) 

DO  (RETURN  (FOR  Y  ON  (REVERSE  X)  WHEN  (EQUAL  (CADAR 

L?) 

DO  (RETURN  (REVERSE  Y]) 


(OEMEWLASEL 
LLAi-idDA  (LABEL) 

( CON  Li 

[UfOrt  LABEL) 

(COND 

( ( HEiiB  LABEL  SECLIST) 

(LIST  (GETP  LABEL  (QUOTE  FIR3TPARA) ) 


Y) 


LABEL)) 

(UEMB  (CADR  SECTION ) 

(GETP  LABEL  ( QUOTE  SECS))) 

(LIST  LABEL  (CADR  SECTION))) 

((EQUAL  (LENGTH  (GETP  LABEL  (QUOTE  SECS))) 

1) 

(LIST  LABEL  (CAR  (GETP  LABEL  (QUOTE  SECS] 

(T  ( ERR  (QUOTE  (NON-UNIQUE  LABEL  REFERENCE] 

(T  LABEL]) 

(GETkECORD 

[LAnriDA  (GARBAGE  LEVELLIST  NArtELIST) 

(*  tni.3  function  takes  a  flat  list  of  record 
descriptions  and  turns  them  into  a  tree  —  in  the 
COBOL  sense,  it  iterates  through  the  list..  ) 

(IF  ( NLISIP  GARBAGE) 

THt,N  (HELP  NIL  "  bad  call  of  GETRECORD" ) ) 

(PROG  (CURRENTLEVEL  CURREN TRECORD  DUitiY) 

(IF  ( NLI3TP  (CAR  GARBAGE)) 

THsN  (HELP  (CAR  GARBAGE) 

"bad  record  description" ) ) 

(SETQ  CURRENTLEVEL  (CAAR  GARBAGE)) 

(IF  uEVELL.IST 

THEu  (IF  ( ILESSP  CURRENTLEVEL  (CAR  LEVELLIST)) 
THEN  (HELP  (CAAR  GARBAGE) 

"  bad  record 


structure" ) ) ) 

(CONS  ( EACH! I HE  (SETQ  CURRENTRECORD  (CAR  GARBAGE)) 

WHILt,  (AND  GAR3AGE  (NOT  (ILESSP  (CAR  CURRENTRECORD) 

CURRENTLEVEL))) 

COLLECT  (IF  (AND  (EQP  (CAR  CURRENTRECORD) 

CURRENTLEVEL) 

(ELEMENTARYP  CURRENTRECORD)) 

Trtfc’N 


(*  here  is  an  elementary  item  at  the  current  level 
—  IT  IS  placed  in  the  symboltable  and  the  pointer 


is  moved  up) 


( INSERTDATA  (CADR  CURRENTRECORD) 
NAMELIST 

(CADDR  CURRENTRECORD) 
CURRENTLEVEL  NIL 
(CAR  (NTH  CURRENTRECORD 
4)) 
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(CAR  (NTH  CURRENTRECORD 
5))) 

(SEi’Q  GARBAGE  ( CDR  GARBAGE)) 
CURRENTRECORD 

EL SEIF  (EQP  (CAR  CURREN I'KECORO) 
CURRENTLEVEL) 

THEN 

(*  here  is  a  group  item  at  the  current  level, 
it  is  put  in  the  symboltable ,  and  the  function  is 
called  recursively  to  handle  tne  elementary  items 
tuat  will  follow,  after  returning,  the  global 
variable  is  reset  and  the  subtree  is  gathered  into 
tne  fold) 

( SETQ  DUMMY 

(GETRGCORD  ( SETQ  GARBAGE 

(CDR  GARBAGE) ) 

(CONS  CURRENTLEVEL 
LEV EL LI ST) 

(CONS  (CADR 

CURRENTRECORD) 
NAMELIST ) ) ) 

( INSERTDATA  (CADR  CURRENTRECORD) 
NAMELIST  NIL 
CURRENTLEVEL 
(GETSONS  (CAR  DUrtWY)) 
(CAR  (NTH  CURRENTRECORD 

4) ) 

(CAR  (NTH  CURRENTRECORD 

5) )) 

(SETQ  GARBAGE  (CDR  DUMMY)) 

(LIST  CURRENTRECORD  (CAT  DUMMY)) 
ELSE  (HELP  NIL  •’  bad  record  structure’))) 

GARBAGE] ) 

( GETrtECORD* 

L LAi-iBDA  (RoCORDLIST)  (*  separates 

7Rdeclarations  from 


tree-structured 
declarations  and  calls 
getrecord  on  the 
tree -structured 
declarations) 

(FOR  (X  ( 7 ( DECS( LIST  NIL)) 

( DAT ADECS( LIST  NIL))) 

IN  RECORDLIST  DO  (IF  (EQP  (CAR  X) 

77) 

THEN  ( NC0NC1  77DECS  X) 

ELSE  (NCONC1  DATADECS  X)) 

FINALLY  [FOR  Y  IN  (SETQ  77DECS  (CDR  77 DECS ) ) 

DO  (INSCRI77ITEM  (CADR  Y) 

(CADDR  Y) 

(CADDDR  Y) 

(CAR  (NTH  Y  5] 

(RETURN  (APPEND  (CAR  (GETRECORD  (CDR  DATADECS))) 


187 


77DECS] ) 


( uE  ISONS 

[ LAnoOA  (TRtn) 

(FOR  X  IN  TREE  COLLECT  (IF  ( NLI5TP  (CAR  X)) 

HEN  (CADR  X) 

ELSE  (CADAR  X]) 

( INSErtl'77 ITEM 

L  L  And  DA  ( NAiiE  PICTURE  OCCURS  VALUE) 

(*  inserts  a  77-item  togetner  with  its  picture, 
checks  for  non-unique  references,  bad  picture, 
modifies  property  list  and  symboltable . ) 

(If  (MULTIPLE  NAME) 

TnaN  (HELP  NAi-iE  'multiply  defined  77-item') 

ELSEIF  (OR  (NULL  (SETQ  PICTURE  (CONVERT  PICTURE))) 

(NOT  (PICTURCOK  PICTURE))) 

1\ieN  (HELP  NAME  ''bad  picture  specification") 

ELSEIF  (NOT  (ATuM  OCCURS)) 

THEN  (HELP  OCCURS  "bad  occurs  expression") 

ELSEIF  (LISrp  VALUE) 

THEN  (HELP  VALUE  "bad  value  statement”) 

ELSE  (ADDPROP  NAmE  (QUOTE  ELEm$) 

(CONS  NIL  (LIST  PICTURE  77  NIL  OCCURS  VALUE))) 
( INSERT VALUE  NAME  VALUE) 

(IJSERTSYmSOL  NAME]) 

( I JSERTD AT A 

lLAmSDA  (NAME  PREDECESSORS  PICTURE  LEVEL  SONLIST  OCCURS  VALUE) 

(*  inserts  an  entry  for  a  ?rouD  or  elementary  data 


item,  checks  for  malformed  predecessor  list,  bad 
picture ,  and  non-unique  data  references.) 

(If  ( NNULL ATOM  PREDECESSORS) 

Then  (HELP  (CONS  NAME  (LIST  PREDECESSORS) ) 

"incorrect  oredecessor  Ii3t”) 

ELSEIf  [NOT  (PICTUREOK  (SETQ  PICTURE  (CONVERT  PICTURE] 
T.iDN  (HELP  (CONS  NAME  (LIST  PREDECESSORS)) 

"incorrect  picture  specification") 

ELSEIF  (MULTIPLE  NAi-iE  PREDECESSORS) 

THEN  (HELP  (CONS  NAME  (LIST  PREDECESSORS)) 

'multiply  defined  elementary  item') 

ELSEIF  (NOT  (NUM6ERP  LEVEL)) 

THL.i  (HELP  LEVEL  'improper  level  soecif ication" ) 
ELStIF  (  NNULLATOfl  SONLIST) 

THEN  (HELP  SONLIST  "not  a  list  of  sons’) 

ELSEIF  (NOT  ( ATuM  OCCURS)) 

T:ic.N  (HELP  OCCURS  "bad  occurs  expression”) 

EL SI If  ( LISTP  VALUE) 

Trtc,N  (HELP  VALUE  "  bad  value  statement") 

ELSE  (ADDPROP  NAME  (QUOTE  ELEM$ ) 


(CONS  PH IDECESS0R3  (LIST  PICTURE  LEVEL  SONLIST 

OCCURS  VALUE))) 

(INSEtu’VALUE  (APPEND  (LIST  (QUOTE  QUAD 

NAME) 

PREDECESSORS) 


VALUE) 
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(  INSERT  JYM80L  WArtE J) 

( INSERTFILE 

[  LAhUDA  (NAME  RCCORDLIST) 

(*  inserts  list  of  records  pertaining  to  a  given 
file,  checks  for  malformed  recordlist  and  multiple 
references. ) 

(Ir’  ( tiilSI'P  RECORDLIST) 

THtN  (HELP  NIL  'IiiP  ROPER  RECORDLIST") 

ELSSIF  (GETP  NAME  (QUO ft,  FILE!) ) 

THuii  (HELP  NAME  "DUPLICATE  RECORD  DECLARATION  ) 

ELSE  (PUT  NAME  (QUOTm  FILE!) 

RECORDLIST) 

( INSERT SYmBOL  NAmE]) 

( INSEHTPAHAGRAPH 

[  LAmBDA  (NAME  SECTION) 

(*  inserts  a  section  for  a  given  oaragraDh. 

two  paragraphs  of  the  same  name  must  be  in  different 

sections . ) 

(If  (FmEmB  SECTION  (GETP  NAME  (QUOTE  PARAGRAPHS ) ) ) 

THEN  (HELP  NAME  "APPEARS  TWICE  IN  A  SECTION") 

ELSE  ( ADDPROP  NAnE  ( QUOTE  PARAGRAPHS) 

SECTION) 

( INSERT SYndOL  tlAiiS]) 

( INSERT. HbCORD 

[LAmBDA  (NAME  FILE)  ( *  inserts  a  rec ordo.ame 

into  the  symboltable, 
with  its  corresponding 
file) 

(IF  (GET?  NAME  (QUOTm  RECORD! ) ) 

THEN  (HELP  NAME  "MULTIPLY  DEFINED  RECORD") 

ELSE  (PUT  NAME  (QuOTc,  RECORD! ) 

FILE) 

(INSERTSYM30L  NAmE]) 

(IASMT  SECTION 

[LAmBDA  (NAME)  (*  inserts  a  section 

name  into  the 
symboltable) 

(IF  (GETP  NAmE  (QUO^  SECTION! ) ) 

(HELP  NAME  ''MULTIPLY  DEFINED  SECTION') 

ELSE  (PUT  NAME  (QUOTt,  SECTION! ) 

( QUOT'i  T)) 

(INSERTSYwBOL  NAilE] ) 

(INSEriTSYMdOL 

LLAiibDA  (NAME)  (*  ails  a  symbol  to  the 

global  variable  that 
represents  the  symbol 
table ) 

[SETQ  SYi'idOLTAriLE  (SORT  (CONS  NAME  (DREMOVE  NAME  SYmRQLTABLE] 

NAmE]) 

(IrtSEdVALdE 

L LAi'idDA  (FULlrAME  NALUESXP) 

(IF  VALJEEXP 

T.iuN  (SETQ  VALUES  (CONS  (CONS  FULLNAriE  VAL’JEEXP) 
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VALUES]) 


( ISA3SERT 


[LArtBDA  (X) 

(AND  (LISTP  X) 

(EQ  (CAR  X) 

(QUOTE  ASSERT]) 

(LABEL.iAKER 

[LAnBDA  ( ABPROG) 

(PROG  (SECLIST  PARALIST) 

[FOR  SECTION  IN  ( CDR  ABPROG) 

DO  (PUT  (CADR  SECTION) 

(QUOTE  FIR3TPARA) 

(CADADR  (CDR  SECTION) ) ) 

(SETQ  SECLIST  (CONS  (CADR  SECTION) 

SECLISD) 

(FOR  PARAGRAPH  IN  (CD DR  SECTION) 

DO  (SETQ  P ARAL I ST  (CONS  (CADR  PARAGRAPH) 

PARALIST) ) 

( ADDPROP  (CADR  PARAGRAPH) 

(QUOTE  SECS) 

(CADR  SECTION] 

(FOR  SECTION  IN  (CDR  ABPROG) 

DO  (FOR  PARAGRAPH  IN  (CDOR  SECTION) 

DO  ( RPLACA  (CDR  PARAGRAPH) 

(LIST  (CADR  PARAGRAPH) 

(CADR  SECTION))) 

(FOR  SENTENCE  IN  (CDDR  PARAGRAPH) 

DO  (CHANGELABEL  SENTENCE] 

(FOP  pARaN ArtE  IN  PARALIST  DO  (REMPROP  PARANAME  (QUOTE  SECS))) 
(FOR  SECNApiE  IN  SECLIST  DO  (REMPROP  SECNAME  (QUOTE  FIRSTPARA]) 

(LAST PARA 


[ LAmSDA  (SEC) 

(FOR  SECTION  IN  (CDR  ABPROG)  WHEN  (EQ  (CADR  SECTION) 

SEC) 

DO  (RETURN  (LIST  (CADAA  (LAST  SECTION)) 

SEC]) 


(LEVEL* 


[LAi-ioDA  (QUALNAHE) 

(SETQ  QUALNAME  (COMPLE I. IL  1ST  QUALNAME)) 
( CADDR  (SASSOC  (CDR  QUALNAME) 

(GETP  (CAR  QUALNAME) 
(QUOTE  ELEM$] ) 


WiAXSIZE 

(LAnBDA  (PIC) 

(*  returns  the  largest  value  that  will  fit  in  the 
picture  correspondin'?  to  a  given  qualified  variable) 
(FOR  (X  YNIL 
LO 
RO) 

IN  (UNPACK  PIC)  DO  (SELECTQ  X 


(S) 

(V  ( SETQQ  Y  T)) 
(9  (IF  Y 


w' 
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Th.SN  (SETQ  R  (SUB1  R)) 
ELSE  (SETQ  L  ( ADD1  L] 

[P  (IF  Y 

Trie*  (S BTQ  L  (SUB1  L)) 
(SETQ  R  ( SUB1  R)) 
ELSE  (SETO  L  ( ADD1  L)) 
(SETQ  R  ( ADH1  R] 

(HELP  PIC  "incorrect  Dicture  )) 
FINALLY  ( RETURN  ( DIFFERENCE  (EXPT  10  L) 

( EXPT  10  R]) 

(.TAXSIZE* 


[LAhBDA  (QUAL'NAHE)  (*  gives  the  "laxi'mim 

size  of  the  value  of 
qualified  variable) 

(rlAXSIZE  (PICTURE*  QUALNAME]) 

(MULTIPLE 

(.LAuSDA  ( NAME  wUALS) 

(OR  [FOR  X  IN  (GETP  NAME  (QUOTE  SLEM$)) 

TNokEIS  (OR  (QUALIFIEROK  (CAR  X) 

QUALS) 

(QUALIFIEROK  QUALS  (CAR  X] 

(FmEMB  NAME  QUALS]) 

( NNULLATJM 


[LAMBDA  (A) 

(AND  A  ( NLISi'P  A]) 

(OCCURS* 

[LAMBDA  (QUALNAME) 

(SETQ  QuALNAME  ( COMP  LET. -,L  1ST  QUALNAME)) 
(CArt  (NTH  (SA330C  (CDR  QUALNAME) 

(GETP  (CAR  QUALNAME) 
(QUOTi  CLEM$) ) ) 
5]) 

(PAIHANAL 

[ LAmBDA  (ScNTLISr  ACCUM  SENT) 

(COND 

((NULL  3ENTLIST) 

(LIST  ACCUM) ) 

(T 

( SbfQ  SEN  I  (CAR  SENTLIST) ) 

(SELECTQ 
(CAR  SEND 


(NEXT  (PATHANAL  (CDR  SEN TL I ST) 

ACCUm) ) 

( ASSEri i  (SETQ  ACCOM  (CONS  SCUT  ACCUM)) 

(SETQ  PATHLiST  (CONS  rtCdJM  PATHLIST)) 
(PATHANAL  (CDR  3ENTLIST) 

(LIST  SENT))) 

[STOP  (SETQ  ACCUM  (CONS  (CADR  SENT) 

ACCUM)) 

(SETQ  PATHLIST  (CONS  ACCUM  PATHLIST) ) 
(SETQ  SENTLIST  (CDR  SEN TL I ST) ) 

(COHO 

( SEN  TL 1ST  (COND 
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[( ISASSErtT  (C AH  SENTLIST)) 

(PATHANAL  (CDR  SEN TLIST ) 

(LIST  (CAR  SENTLIST} 

(T  NIL))) 

(T  ( QUOTt  (  END] 

[GO  (Sc,TQ  TEMP  ( SASSJC  (CADR  SENT) 

LA3SLA3SCRTLIST)) 

[COND 

((NULL  TEaP) 

( HELP  ( QUO T E  (GOTO  TARGET  HAS  NO  ASSERTION] 

(ScTQ  ACCUii  (CONS  (CDR  TEMP) 

ACCUt  l) ) 

(SETQ  P ATHEIST  (CONS  ACCUM  PATHLIST) ) 

( StTQ  SENT LIST  (CDR  SEN TL I ST) ) 

(COW 

(SENTLIST  (COND 

[(ISASSShT  (CAR  SENT LIST)) 

(PATHANAL  (CDR  SENTLIST) 

(LIST  (CAR  SENTLIST] 

(T  NIL))) 

(T  ( QUOTE  (END] 

[IF  (UNION  (PATHANAL  (CONS  ( CADDR  SENT) 

(CDR  SENTLIST)) 

(CONS  (LIST  (QUOTE  IF) 

(CADR  SENT) ) 

ACCUii) ) 

(PATHANAL  (CONS  ( CADDDR  SENT) 

(CDR  SENTLIST)) 

(CONS  (LIST  (QUOTE  IF) 

(LIST  (QUOTE  NOT) 

(CADR  SENT))) 

ACCUrl] 

l HLOCK  (UN UN  ( FOR  X  IN  (PATHANAL  (CDR  SENT) 

Accua) 

JOIN  (COND 

(<EQ  X  ( QUOTE  END)) 

(COND 

[ ( ISASSE3T  (CADR  SENTLIST)) 
(PATHANAL  (CDDR  SEMILIST) 

(LIST  (CADR  SENTLIST] 

( r  NIL))) 

(T  (PATHANAL  (CDR  SENTLIST) 

X] 

U.JJPA..„„.<  i  (  StTQ  ACCU.1  (CONS  (CADR  SENT) 

ACCUii) ) 

(St IQ  “ATHLIST  (CONS  ACCUii  PATHLIST)) 

(LIST  (  QUOTi.  .ND) )  ) 

(ENuPERrOR.i  (LISI  ACCUM)) 

(PATHANAL  (CUR  S'NTLIST) 

(CONS  (CAM  SENTLIST) 

ACCUii] ) 

( p;crjH..» 

[  LAuDDA  (QUAL'IArlE ) 
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(SETQ  QUALNAME  ( COMPLETELIST  Q UALNAME)) 

(CADft  (SASSOC  (CDR  QUALNAME) 

(3ETP  ( CAR  QUALNAME) 

(QUOTE  ELEM$] ) 

(PICTUREUK 
[ LAMBDA  (PIC) 

(OR  (NULL  PIC) 

(AND  (ATOM  PIC) 

(FOR  X  IN  (UNPACK  PIC)  ALWAYS  (FMEM8  X  PICTtJRECHARSl ) 

( PRcPHOCESo 

[  LAMBDA  (AdPROJ  FLAG) 

(PROG  (FLATSECTEXT  FLATPARATEXT  (TEXT  (COPY  ABPROG) ) ) 

(DEBJGPRINT  TEXT  INPUT-PROGRAM  1) 

(LABELMAKER  TEXT) 

( DEBUGPRINT  TEXT  AFTER-L ABEL. tAKER  2) 

( SETQ  FLATSECTEXT  ( FLATTENSECTIONS  TEXT)) 

(DEBUG PRIM?  FLATSECTEXT  AFTER- FLATTEN SECTION  P) 

(SETQ  FLATPARATEXT  ( FLATTENPARAS  FLATSECTEXT)) 

( DEBUG PRINT  FLATPARATEXT  AFTER- FLATTENPARAS  4) 

(SETQ  FLATPARATEXT  ( SENTENCESCAN  FLATPARATEXT)) 

(DEBUGPRINT  FLATPARATEXT  AFTER-SENTSNCESCAN-IN-PRSPROCESS  S]) 

(QUAL 

[LAmBDA  (QUALNArtE) 

(COND 

((NL IS TP  QUALNAME) 

(LIST  (QUOfc,  QUAL) 

QUALNAME) ) 

( ( NEQ  (CAR  QUALNAME) 

(QUOTE  QUAL)) 

(HELP  QUALNAME  "improper  qualifier")) 

(T  QUALNAME]) 

( QU ALIFIEROK 

[LAMBDA  ( QUAL LI ST  PREDLIST) 

(COND 

((NLISTP  QUALLI3T) 

T) 

((NLISTP  PREDLIST) 

NIL) 

(T  (PROG  (Z) 

(SETQ  Z  ( FMEMB  (CAR  QUALLIST) 

PREDLIST)) 

(RETURN  (CO'.V 

((NLISTP  Z) 

NIL) 

(T  ( QU ALIFIEROK  (CDR  QUALLIST) 

(CDR  Z]) 

( RECORDLIsr 
[LAi-iBDA  ( NAME) 

(  GETP  NAME  (QUOTl.  FILE$] ) 

( ReCORDNAmE 

L LAmBDA  (FILE) 

(CArt  (RECORDLIST  FILE]) 

( SccrioNLisr 
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I L And DA  (NAME) 

( GETP  NAME  (QUOTE  PARAGRAPH$  ] ) 

(3ECTI0NP 

[LAnBDA  (NAME) 

(GETP  NAME  '.QUOTE  SECTION*]) 

(SENTENCESCAN 
L  L Ant) DA  ( TEXT’) 

(PROG  NIL 

(FOR  SENT  IN  I  XT 
JOIN 

(APPEND  ( SELECT Q 

(CAR  SEND 

(OPENINPUTi  (SENTEiJCESCAN  ( #0PENIM  SENT))) 
(OPENOUTPUT*  ( SENTEMCESCAN  ( tfOPENOUT  SENT))) 
(  READ  (SENTENCE3CAN  ( 0RSAD  SENT))) 

(WRITE  ( SEN  TSiCESCAN  ( *  WRITE  SENT))) 

(IF  (#IF  SENT)) 

( PERFORM  ( # PERFORM  SENT) ) 

(SET$  ( #SET*  SENT)) 

(SET ROUNDED*  ( #S£TROUNDED$  SENT)) 

( MOVECORRE3PONDING$  ( SENTENCESCAN  ( 

(MOV BCOR RESPONDING*  SENT))) 

( ADDCORRESPONDING*  ( SENTENCESCAN  ( 
tfAOOCOR RESPONDING*  SENT))) 

( SUBTRACTCORRSSPONDING*  ( SENTENCESCAN 

( 

»SUBTRACTC0RRE3P0NDING$  SENT) ) ) 

t LOOP ASSERT  (LIST  (CONS  (QUOTE  LOOPASSEBX) 

(SENTENCESCAN 
(CDR  SENT] 

(ASSERT  ( ((ASSERT  SENT)) 

( DISPLAY  NIL) 

(ACCEPT  NIL) 

(LIST  SENT]) 

( sows 

(  LAi-ujDA  (QUALNAME) 

(SETQ  QUALNAME  ( COrfPLETELIST  QUALNAME)) 

(FOR  X  IN  [ CADDDR  ( SAS50C  (CDR  QUALMAME) 

(GETP  (CAR  QUALNAME) 

(QUOTE  EL EM*] 

COLLECT  (APPEND  (LIST  (QUOTE  QUAL) 

X) 

QUALNAME]) 

( VALUE* 

[LA.iBDA  ( QUALNAME ) 

(Sc,TQ  QUALNAME  (COMPLETELIST  QUALNAME)) 

(Car  (NTH  (SASSoC  (CDR  QUALNAME) 

(GETP  (CAR  QUALNAME) 

(QUOTE  SLEM*))) 

6]) 

(VC 

(LAmBDA  ( ABPROG) 

(PROG  (PATHLISf  FLATSECTEXT  LABELAS3ERTLIST ) 
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( LASELrtAKKW  A3Pf iDG) 

(SETQ  FLATSECTEXT  ( FLATTENSECTIONS  ABPR03) ) 

(FETCHLABELA S3ERTI0N3  FLATSECTEXT) 

(SEl'Q  SCANOUT  ( SENTlNCESCAN  ( FLATTEN  PARAS  FLATSECTEXT) ) ) 
(PATHANAL  ( CDR  SCANOUT) 


(LIST  (CAR  JCiWU T))) 

(Sc. IQ  PaThANALOUT  PATHLI3T) 

( SLTQ  VCOUT  ( COBOLVCG  PATHLIST) ) 

(RETURN  VCOUT]) 

(VLSI 

[LAi'idDA  (PATH  FORM) 

(COND 

((NULL  PATH) 

FORM) 

(T  (3ELECTQ  (CAAR  PATH) 

(ASSERT  (LIST  (QUOTE  IMPLIES) 

(CADAR  PATH) 

FORM)) 

(IF  (VCG 1  (CDR  PATH) 

(LIST  (QUOTE  IMPLIES) 

(CADAR  PATH) 

FORM) ) ) 

(ASSIGN  (VCG1  (CDR  PATH) 

(3U83T  (COND 

((AND  { LISTP  (CADAR  PATH)) 

(SQ  (CAADAR  PATH) 

(QUOTE  SELECT))) 
(LIST  (QUOTE  CHANGE) 

(CADR  (CADAR  PATH)) 

( CADDR  (CADAR  PATH)) 
(CADDAR  PATH))) 

(T  ( CADDA.R  PATH))) 

(CADAR  PATH) 

FORM)) ) 

( VCG1  (CDR  PATH) 

FDfii-l] ) 

(Zap 

L LA.iBDA  NIL 
(PROG  NIL 

(SErO  ZZZ  (COP*  i-iIKE/A) ) 

(RETURN]) 

) 

( DECLA.il:  juNTlVAL^LOAD  DO- VAL^COMPILE  DONTCOPf  COMPILER!' ARS 
(ADDTuVAa  NLAiiA ) 

UDjTGVAR  NLA.il  DE9U SPRINT) 

) 

( DECLAMo :  DONTCOPT 

(  FIlEi-iAP  (NIL  (  1274  284  12  ( #ADDCORRESPONDINGA  1296  .  1628)  (  # ASSERT 
1532  .  1708)  ( #1F  1712  .  2202)  ( #uOVSCOBflcoPONDING$  2205  .  2’MO)  ( 
j/OPDJL-i  2414  .  2524)  (  #  OPEN  OUT  2523  .  2570)  (^PERFORM  2374  .  4409) 
URCAD  4412  .  5J41)  (fSuM  504  1  .  5387)  ( ASETqOU'lDED$  5501  .  SIR1 ) 

(  rfSUBTKrtLrCORRL.  IPONDING-i  61  35  .  5486)  (  ♦ WRITE  6H90  .  7139)  (AnBIGlJOUS 
7142  .  Mjj)  (A5S..W  1  7470  .  7  72?)  (ChANGELABEL  7724  .  3454)  (COBOLVCG 
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8458  .  8589)  ( COMPLETELIST  8593  .  9005)  (CONVERT  9009  .  9667)  ( 
CORRESPAIftS  9671  .  10052)  ( DEBUGPRINT  10056  .  10346)  ( ELEMENTARY P 
10350  .  10608)  ( ELEMITEMSOF  1061?  .  10724)  (ERASETABLE  10723  .  11098) 
(ERR  11102  .  11152)  ( FETCHL  ABEL  ASSERTIONS  11156  .  1 1 36 1 )  (FILE  m65 
.  11609)  (FILENAME  11613  .  11665)  ( FLATTENPARAS  11669  .  11753)  ( 

FLATTEN SECT IONS  11757  .  11856)  (GATHERPARAS  11860  .  12063)  (GETNEWLABEL 
12067  .  12481)  (GETRECORD  12485  .  14789)  (GETRECORD*  14793  .  15671) 

( GET30NS  15675  .  15800)  ( INSERT77ITEM  15804  .  16538)  ( INSERTDATA  16542 
•  17749)  (INSERTFILE  17753  .  18 183)  ( INSERTPARAGRAPH  18137  .  18563) 
(INSERTRECORD  18572  .  19014)  ( INSERiSECTION  19018  .  19392)  ( INSERTSYilBOL 
19396  .  19761)  (INSERTVALUE  19765  .  19891)  ( ISASSEPT  19895  .  19*577) 

( LABELnAKER  19981  .  20811)  (LASTPARA  208 15  .  20970)  ( LEVEL*  20974 
.  21130)  (MAXSIZE  21134  .  21726)  (MAXSIZE*  21730  .  21987)  ( MULTIPLE 
21991  .  22182)  (NNULLATOM  22186  .  22235)  (OCCURS*  22239  •  22418)  ( 
PATHANAL  22422  .  24353)  (PICTURE*  24357  •  24512)  (PICTUREOK  24516 
.  24b42)  ( PREPR0CE3S  24o4o  .  25223)  (QUAL  25227  .  25440)  ( QUALIFTEROK 
25444  .  25746)  ( RECORDLIST  25750  .  25810)  ( RECORDNAhE  25814  .  25872) 
(StCTIONLIsr  25876  .  25942)  (SECTIONP  25946  .  26007)  ( SENTENCESCAN 
26011  .  26816)  (SONS  26820  .  27068)  (VALUE*  27072  .  27250)  (VC  27254 
.  27701)  ( VCG1  27705  .  28314)  (ZAP  28318  .  28409))))) 

STOP 
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